关于VC运行时绑定

写在译文之前：许多人都在纳闷为啥VS2005编译的程序需要安装一个运行时，而2008的却只需要安装2005的运行时呢？也许因此有了本文的诞生。

下面是内容：

原文作者是George Mileka，在VC team里面写库的。原文链接：VC team blog

在四月发布了Visual C++ 2008 Feature Pack之后我们收到了很多来自MVP和用户的反馈。其中一项必须要澄清的问题是在嵌入程序的manifest文件中的依赖项版本的问题。

问题是这样的： 为什么 VS team 提供了如下两个选项：

    (1) 将程序绑定到RTM版本的VC运行时。

    (2) 将程序绑定到当前版本的VC运行时。

那么，哪个是默认的行为呢？

在讲解上述两种情况都是有用的之前我想要强调一下……

VC提供的策略重定向将程序对旧版本的请求重定向到新版本（这种重定向是有底线的*，且必须在.config文件存在的情况下**）。

这意味着：

    - 绑定到RTM版本的链接库的应用程序可以在RMT或者以后的版本的链接库环境下运行（或者更新的版本也可以）。

    - 绑定到当前版本的链接库的应用程序可以被在当前版本的链接库环境下运行（如果有新版本发布依旧可以运行）。

现在，来回答刚才的问题。

选项 (1) 适用于下列场合：

- 艾伦安装了RTM的版本并且用来开发自己的产品。

- 艾伦构建了自己的产品然后和他所有的VC运行时dll（RTM版本）打了个包。

- 微软发布了 VS SP1, 用户安装了SP1以修复缺少链接库的问题（也许某些情况下是性能问题，这只是个例子）。

- 艾伦在自己的产品里面发现了新的bug并决定修复它，然后重新构建可执行程序发布一个补丁给客户。

在这个场景中，艾伦不需要关心新的VC运行时dll。艾伦可以重新构建可执行程序，然后交付到客户手中，而不需要再给出一份VC运行时。为了避免应用程序对新VC运行时dll的依赖，用户（译者：这里指的是艾伦）选择绑定到RTM版本的dll。

选项(2) 适用于下列情况：

- 吉姆安装了RTM版本并用它开发了自己的产品。

- 吉姆发现VC的库有问题，而且这个问题对他的产品影响很大。

- 吉姆请求微软修复该问题（请求一个QFE）以使自己的产品工作正常。

- 微软修复了问题，并给吉姆一个该修复的QFE。QFE可能包括新的头文件、库文件和运行时dll。

- 吉姆构建他的产品然后和他得到的QFE中的VC运行时dll一同发布。

在这个场景中，吉姆产品正常运行要依赖于新的运行时dll。所以吉姆选择要么正确要么不干的方式。并且通过绑定QFE版本的运行时dll贯彻了这个想法。

对于VS2005默认行为（不受到SP1的影响）是场景2。

对于VS2008默认是场景1。

默认行为不一致的原因（根据用户的反馈）是场景1比场景2更常见。

你可以和我们抱怨说该根据不同的发布情况有不同的默认行为（QFE对比SP1）。而我们认为这个会比一个策略用于所有情况更让人疑惑。

如果你有其他问题，请告诉我（译者：这里说的是原文作者，译者可不是权威）……

* 这里的“底线”指的可以是VS RTM、VS SP1等等。

**  .config 完全可以用来禁止首要的策略或者在首要策略实施之前将应用程序的请求映射到其他某个东东。

___________________________________________________________________________

写在译文之后：

感谢Jamie给予关于“going into”的小小帮助。

文章来的晚了些，不知道有木有人看了。

___________________________________________________________________________

补充：

在Feature pack中如果想改变绑定的方式，可以在stdafx.h的开头定义

_BIND_TO_CURRENT_MFC_VERSION 1

或者

_BIND_TO_CURRENT_CRT_VERSION 1

(还有一个宏的名字是 _BIND_TO_CURRENT_VCLIBS_VERSION，原本打算用它，但是它会引入很多bug，所以不要使用了).

注意，以上的宏定义对于常规的MFC DLLs和/clr选项是没用的。不过等到出sp1的时候这些问题都会被修正。