我有一个项目取决于特定版本的MSVCR80.dll（MS Visual C运行时），我遇到了问题，根据特定的系统配置，我的应用程序并不总是得到该文件的正确版本。对于找到具有该名称的文件所需的路径来说，这是一个废话，但它并不总是正确...
在VS2005中创建部署项目时，有没有办法确保我的应用总是使用我提供的运行时？当我将运行时文件添加到项目中时，它会询问有关创建合并模块的信息......但不确定这是做什么的。无论创建一个，问题仍然存在。
答案 0 :(得分：2)
Martin Richter在CodeProject上写了一篇关于它的文章： Create projects easily with private MFC, ATL and CRT assemblies
此解决方案不依赖于您的MSI包，而是依赖于使用CRT文件的应用程序。
答案 1 :(得分：0)
我不确定安装后的应用程序是否无法正常工作，或者它是否是您在安装过程中使用的无法使用的DLL？
非常简短：新版本的C / C ++运行时安装为 Win32程序集，或并行安装。这意味着文件将进入 C：\ Windows \ winsxs - 相当于GAC的Win32 下的文件夹中，同一文件的多个版本可以共存。
使用 Visual Studio 2005/2008 编译的应用程序会将清单文件放入二进制文件中，此清单指定并行运行时版本到绑定到。如果您将MSVCR80.dll放在EXE旁边或甚至在system32中都没关系 - EXE中嵌入的清单将从 C：\ Windows \ winsxs 加载文件。
这都是“完整的圆圈”。在过去，运行时去了System32。这导致原始dll-hell ：应用程序覆盖彼此的全局运行时文件。为了解决所有这些问题，我们的想法是“隔离变更”到每个应用程序。因此，新方法是在EXE旁边隔离运行时文件的本地副本。现在这引发了一个全新的问题：如何确保部署隔离dll的安全更新？在大多数情况下，这种情况从未发生过，并且您有许多应用程序使用本地的，不安全的dll运行。那么该怎么办？决定引入dll-hell的第二次出现：并排组装方法。在这种方法中，运行时不是本地的，而是全局的 - 具有支持并排安装的关键差异。这样，理论上，应用程序可以在不覆盖彼此的运行时dll的情况下运行。
这就是“如何使运行时部署变得复杂”的快速摘要。我不是肯定的，它仍然可以做，但你是否检查过你是否可以静态链接到运行时？有时候老派真的很容易......