{"id":4973,"date":"2008-05-15T20:04:00","date_gmt":"2008-05-15T20:04:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/2008\/05\/15\/vc-runtime-binding\/"},"modified":"2019-02-18T18:54:05","modified_gmt":"2019-02-18T18:54:05","slug":"vc-runtime-binding","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/vc-runtime-binding\/","title":{"rendered":"VC Runtime Binding…"},"content":{"rendered":"

Hello, I am George Mileka, a developer on the Visual C++ Libraries Team. <\/span>After we released the Visual C++ 2008 Feature Pack<\/a><\/span> back in April, we got a lot of useful feedback from MVPs and customers. One of the areas that definitely needed clarification is the version dependency embedded in the generated manifest.<\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

The question goes like this: Why does the VS team provide two options: <\/font><\/p>\n

    (1) bind the application to the RTM version of the VC runtimes.<\/font><\/p>\n

    (2) bind the application to the current version of the VC runtimes.<\/font><\/p>\n

And what is the default behavior?<\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

Before going into why each case can be useful, I’d like to emphasize something…<\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

The policy redirection provided by VC redirects application requests for older versions to newer ones (for a given servicing baseline*, and after applying the <app>.config file if present**)<\/span>.<\/font><\/p>\n

This means that:<\/font><\/p>\n

    – an application that binds to the RTM version of the libraries can be directed to RTM or later (if a newer runtime is installed).<\/font><\/p>\n

    – an application that binds to the current version of the libraries can be directed to the current version (or later version when a newer version is released). <\/span><\/font><\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

Now – back to answering the question.<\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

Option (1) is useful for the following scenario:<\/font><\/p>\n

– Alan installs the RTM product and uses it to develop his product.<\/font><\/p>\n

– Alan builds his product and ships the VC runtime dlls he has along with it (RTM ones).<\/font><\/p>\n

– Microsoft releases VS SP1, and the user installs it to get a fix for a non-libraries related issue (perf improvement in some area for example).<\/font><\/p>\n

– Alan finds a bug in his own product and decides to fix it, rebuild his binaries and ship a patch for his customers.<\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

In this scenario, Alan does not really care about the newer VC runtime dlls. Alan should be able to rebuild his binaries, and hand them to customers without having to redistribute the VC runtime. To decouple the new application binaries from the new VC runtime dlls, the user chooses to bind to the RTM version of the VC runtime dlls.<\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

Option (2) is useful for the following scenario:<\/font><\/p>\n

– Jim installs the RTM product and uses it to develop his product.<\/font><\/p>\n

– Jim finds a problem with the VC libraries. The problem affects his product behavior. <\/font><\/p>\n

– Jim asks Microsoft for a fix (a QFE) so that his product works properly.<\/font><\/p>\n

– Microsoft fixes the problems and hands Jim a QFE with the fix. The QFE contains new headers\/libraries\/runtime dlls.<\/font><\/p>\n

– Jim builds his product and ships the VC runtime dlls he got through the Microsoft QFE.<\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

In this scenario, Jim’s product correct behavior is dependent on the newer runtime dlls. Jim prefers that his application does not start at all rather than starting and inhibiting incorrect behavior. Jim can enforce that by binding to the QFE version of the runtime dlls.<\/font><\/p>\n

<\/font> <\/p>\n

In VS2005, the default (out of the box after installing SP1) is Scenario #2.<\/font><\/p>\n

In VS2008, the default is Scenario #1.<\/font><\/p>\n

<\/font> <\/p>\n

The reason we have switched the default behavior is that (based on customer feedback) scenario #1 is way more common than scenario #2.<\/font><\/p>\n

<\/font> <\/p>\n

One can argue that we could have had different defaults based on the release context (QFE vs. SP1), but we think this will be more confusing than just sticking with one policy for everything.<\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

[Added 9\/30\/2009] If you are interested in how either scenario can be implemented, please see MSDN article<\/font>:<\/font><\/span> <\/span>http:\/\/msdn.microsoft.com\/en-us\/library\/cc664727.aspx<\/font><\/a> <\/p>\n

<\/span><\/font><\/font><\/p>\n<\/p>\n

<\/font> <\/p>\n

Please, let me know if you have any questions…<\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

George Mileka<\/font><\/p>\n

Visual C++ Development Team<\/font><\/p>\n

<\/p>\n

 <\/font><\/p>\n

<\/span><\/p>\n

* A “servicing baseline” can be VS RTM, VS SP1, etc. <\/p>\n

<\/font><\/font><\/span><\/p>\n

**  The <app>.config can be used to disable the central policy altogether – or it can map the application request to something else before the central policy is applied.<\/p>\n

<\/font><\/font><\/span><\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

Hello, I am George Mileka, a developer on the Visual C++ Libraries Team. After we released the Visual C++ 2008 Feature Pack back in April, we got a lot of useful feedback from MVPs and customers. One of the areas that definitely needed clarification is the version dependency embedded in the generated manifest.   The […]<\/p>\n","protected":false},"author":289,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-4973","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus"],"acf":[],"blog_post_summary":"

Hello, I am George Mileka, a developer on the Visual C++ Libraries Team. After we released the Visual C++ 2008 Feature Pack back in April, we got a lot of useful feedback from MVPs and customers. One of the areas that definitely needed clarification is the version dependency embedded in the generated manifest.   The […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/4973","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/289"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=4973"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/4973\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=4973"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=4973"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=4973"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}