我有一个项目依赖于特定版本的MSVCR80.dll（MS Visual C运行时），我遇到了问题，根据特定的系统配置，我的应用并不总是获得该文件的正确版本。关于用这个名字找到一个文件需要什么路径，这是一个废话拍摄，它并不总是正确的...在VS2005中包含MS C++运行时生成的MSI
有没有办法，当在VS2005中创建一个部署项目，到保证我的应用程序将总是使用我提供的运行时？当我将运行时文件添加到项目中时，它会询问有关创建合并模块的信息......但并不确定它会做什么。而不管创建一个，问题依然存在。
马丁·里克特写某篇文章在CodeProject： Create projects easily with private MFC, ATL and CRT assemblies
该解决方案不依赖于MSI包，但对使用的CRT文件的应用程序。
我不确定它是否是您的应用程序安装后不起作用，或者如果它是您使用作为安装不起作用的一部分的DLL？要做一个很长的故事，很简短：新版本的C/C++运行时安装为Win32程序集或并排安装。这意味着这些文件将进入文件夹C：\ Windows \ winsxs - GAC的Win32等效项，并且可以在此共存同一文件的多个版本。
应用程序与的Visual Studio2008分之2005编译会放一个清单文件成二进制，而这个清单指定什么并排端运行时版本绑定到。将MSVCR80.dll放在EXE或甚至是system32的旁边并不重要 - 嵌入在EXE中的清单将从加载文件C：\ Windows \ winsxs。
这是所有“完整的圆”。在过去，运行时间进入System32。这导致原始的dll-hell：应用程序覆盖彼此的全局运行时文件。为了弥补这一切，这个想法是为每个应用程序“隔离更改”。因此，新方法是隔离EXE旁边的运行时文件的本地副本。现在，这引发了一个全新的问题：您如何确保部署隔离dll的安全更新？在大多数情况下，这绝不会发生，并且你有很多应用程序在运行本地，不安全的dll。那么该怎么办？决定是介绍dll-hell的第二次来临：并排组装方法。在这种方法中，运行时不是本地的，而是全局的 - 与支持并行安装的关键区别。这样，理论上，应用程序可以在不覆盖彼此的运行时DLL的情况下运行。
这就是“如何使运行时部署变得复杂”的快速总结。我不积极，它仍然有可能做，但你检查你是否可以静态链接到运行时？有时老派真的更容易...
不幸的是，我不能真正修改应用程序... – 2009-05-18 12:57:49