在寻找Msvcr71.dll一些旧应用程序所需的缺失内容的权威来源时，我偶然发现了 MSDN 文章Visual C++ 中共享 C 运行时组件的重新分发。给开发人员的建议是将 DLL 放入应用程序的目录中，而不是，system32因为此目录中的 DLL 在系统路径之前被考虑。
如果我（作为管理员，而不是开发人员）决定采取偷懒的方式并将其安装到目录（32 位 Windows XP 或 Windows 7 系统）中，而不是将副本放在每个应用程序的目录中，那么会出现什么问题Msvcr71.dll？Msvcp71.dll有system32没有其他好的解决方案可以为应用程序提供所需的 DLL，而无需将内容复制到应用程序目录？
在第一个答案之后添加：我理解不兼容的 API 更改可能已经针对上述 DLL 进行了修复，但我使用 Google 发现的几乎每个不兼容问题都与游戏或视频编解码器有关。目前，我预计损坏的风险非常小。我是否遗漏了什么？
答案1
主要（唯一？）问题是 Msvcr71.dll 的不同版本之间的兼容性。假设 7.10.0 与 7.10.1 略有不兼容，并且应用程序 App1 依赖于旧行为，而应用程序 App2 依赖于新行为。此外，这两个应用程序本身都不附带此 C++ 运行时。在这种情况下，两个应用程序中的一个将失败。
这些情况有多常见？我真的不知道，但我认为很少见。
根据 msvcr71.dll 版本之间的差异，应用程序可能无法启动或特定功能无法运行。
另一个好的解决方案是：每个应用程序都有自己的 PATH。例如，您可以编写如下批处理：
PATH=c:\PathToMSVCR71.DLL_Version_7.10.0
myapp1.exe
这样，您可以在多个应用程序中重复使用同一个 DLL，并更轻松地更新它。
编辑
几乎不可能估计版本冲突的危险，尤其是您没有提到您使用的应用程序。这就是为什么我在我的电脑上搜索了所有不同的版本（Windows 7/x64）。我找到了以下文件：
所有文件都只是这两个文件的副本：7.10.3052.4 和 7.10.6030.0。7.10.3052.4 也是 dll-files.com 提供的。
我还比较了这些版本的输出dumpbin /imports /exports msvcr71.dll，发现出口和进口都没有改变（正如预期的那样）。
答案2
您链接的文章中的“更多信息”说，将 CRT 放在 system32 中“可能会导致在未安装正确版本的 CRT DLL 的计算机上运行链接到不同版本 CRT 的应用程序时出现问题”。
例如，假设 App1 需要 2.1 版 Msvcr71.dll 才能运行其 SpinMyRainbowPinWheel 功能。App1 的开发人员将 Msvcr71.dll 安装在 App1 的程序文件目录中。
如果您将 2.0 版 Msvcr71.dll 放入 system32，App1 将开始使用系统文件，而不是安装在其程序文件目录中的文件。SpinMyRainbowPinWheel 功能将不再起作用，并且您会接到 CEO 的电话，因为当他对着麦克风吹气时，风车没有在他的显示器上旋转。业务戛然而止！
答案3
不要，我再说一遍，永远不要替换或添加系统范围的 DLL。我不明白为什么你不能直接捆绑它？这就是你创建安装程序包的原因。我知道微软有一个带有 VS6 的安装创建工具，如果你没有它，那么你可以使用类似 innosetup 的工具。他们告诉你将 DLL 放在同一个文件夹中的原因是，据我所知，应用程序首先会在那里查找 DLL。
除此之外，我想到两件事：
1) DLL 可能已存在于相关系统中
2) 如果不存在必要的 DLL，我相信 Microsoft 会提供安装包来安装它们。我建议您使用这种方法，而不是随意替换/添加 DLL 文件。
我使用 GTK 的经历完美地说明了为什么你不应该接触系统范围的 DLL。不同的应用程序使用不同版本的 GTK。我记得有一个应用程序决定“偷懒”，为 GTK 安装了一个系统范围的 DLL。使用 GTK 的其他应用程序不再工作了。