如果在Visual Studio 6中内置，则不再加载DLL 我正在研究Visual Studio 2005 C++应用程序。对于网络，它使用Visual Studio 6中内置的网络协议DLL。（DLL开发人员对旧工具发誓。）

在某个时候，VisualStudio6项目被另一个开发人员更新到2005年。DLL已重建，但无法工作。无论如何，他们决定降级回6级。我没有意识到这一点，所以我加载了2005

.vcproj

并构建了它。我不确定那是不是导火索，但我怀疑是的

现在，如果DLL是在6中构建的，我无法在我的机器上加载它。Windows的行为就像

.dll

文件不存在一样。如果我使用VisualStudio2005构建产品，它会正确加载并运行，但某些功能会被破坏。解决方案是从2005年开始升级和调试，但另一个开发人员希望继续使用VS6。然而，它在其他计算机上也能工作。所有人都在运行XP Professional SP3

如果我将程序目录从正在工作的安装复制到我的，

.exe

和

.dll

以及所有目录，它将停止工作。这是什么原因造成的

---

我使用了免费的ProcessExplorer程序，并验证了没有加载任何其他类似的DLL，也没有在我预期的情况下在工作安装的机器上加载任何DLL。

这些问题的根本原因是您混合了不同的运行时库：VS6 DLL使用msvcr60.DLL，而VS2005 DLL使用msvcr70.DLL（也就是说，除非有人告诉VS2005根据VS6框架进行编译，但这不太可能）。典型的问题示例：应用程序通过msvcr70进行分配，将该内存块传递给dll，dll使用msvcr60进行释放，但该dll使用不同的堆。Bang

---

这里真正的解决方案是制造一切（应用程序和DLL）使用相同的运行时，或者换句话说：升级到最新的VisualStudio版本。它不起作用只是表明代码编写得相当糟糕或者使用了过时的功能；在这两种情况下，一个健康的解决方案都是重构，而不是摆弄一个几乎过时的编译器。假设另一个开发人员坚持使用g VS6，5/10/15年内会发生什么？他有什么真正好的理由坚持使用VS6吗？

在你写答案时，我们同意升级：）。在这方面，我们可能很快也会升级到2008年或2010年。值得一提的是，我们仔细检查了运行库在工作系统和非工作系统之间是否相同。