（转）

自打vs2005里面引进了manifest的概念后，编译完运行时诸如“应用程序正常初始化失败”的问题就层出不穷。其本质原因就是程序的manifest（不管是内嵌的还是单独的manifest清单文件）中指定的运行库在系统里找不到。于是乎在网上找答案，开始深陷于WinSxS下的一堆泥潭之中。尤其是编译好的程序要放到全新的系统上执行时，WinSxS下哪些需要拷贝，哪些不需要，这些是一个完全让人头疼的问题，不得不说微软搞的这套东西很二。为了弥补，微软提供了vcredist_x86.exe，安装完后对应的运行库就可以配置到WinSxS下面去了。不过这个只是release版本，对于debug版本，你还得老老实实拷贝那些该死的manifest，policy，和dll到对应的系统目录下去。另外一个问题就是要发布自己的软件时，带个微软的安装包总显得有点不伦不类。

        当然还有一个解决方法，就是拷贝vs2005安装目录中Microsoft Visual Studio 8\VC\redist\x86下的Microsoft.VC80.CRT到应用程序所在的目录。但是问题来了，在没有安装sp1的vs2005下是不能成功的，问题仍然是“应用程序正常初始化失败”。后来比较应用程序的manifest和Microsoft.VC80.CRT下的manifest才发现：用vs2005生成的exe，dll中的依赖库版本为8.0.50608.0，而运行库目录里的manifest的版本号是8.0.50727.42。在安装了vs2005的WinSxS目录下甚至都找不到8.0.50608.0这个版本，那为何上能够正常运行呢？原因是这里微软又耍了个小聪明，policy文件里可以指定运行库版本的映射，于是你能发现policy文件里诸如

<bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0" newVersion="8.0.50727.42"/>

的语句，所以在这样的系统下，系统运行该应用程序时，实际上是加载的8.0.50727.42的运行库。

         vs2005生成的应用程序的依赖库版本不一致大概是微软的一个bug，详见http://social.msdn.microsoft.com/Forums/zh-CN/vcgeneral/thread/fd894fd3-4da0-4048-af14-2b32ddda82b9   这个bug带来一个问题，我们似乎没法将运行库打包到应用程序中，因为虽然manifest和dll可以拷贝到应用程序目录，但是policy文件拷过来是不起作用的。

       最后的解决办法是：既然8.0.50608.0可以映射到8.0.50727.42，那我为何不可以将Microsoft.VC80.CRT.manifest中的版本号从8.0.50727.42改成8.0.50608.0呢？这样就可以和应用程序的依赖库版本一致了，虽然那三个dll仍然是8.0.50727.42的，但是不影响加载。

       总结一下，发布vs2005生成的应用程序时：

1. 拷贝Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT目录到应用程序目录下

2. 修改Microsoft.VC80.CRT.manifest文件，将版本改成8.0.50608.0

       这样就免去那些WinSxS下的一堆复杂文件之苦了。对于debug版本也同样适用。