msxml .dll的奇怪行为

Question

突然之间，当程序试图实例化一个MSXML2.DOMDocument时，我们的一些客户遇到了ActiveX组件无法创建对象错误。我们在这里讨论的是一个在计算机上编写的VB6应用程序，它设置了对msxml2.dll的引用，而不是其他xml-dll。当我们发布部署时，我们每次都会部署msxml2.dll、msxml2a.dll和msxml2r.dll，并且从来没有出现过任何问题。

这次不行!这就好像windows环境本身已经改变，拒绝了注销/重新注册过程。无论我做什么，我都无法让客户端计算机成功地实例化MSXML2.DOMDocument。更奇怪的是:当我重命名/注销/删除system32文件夹中的所有msxml2*文件时，没有遇到该问题的客户端仍然可以正常工作，因此它们似乎不需要.dll！通常，此客户端将混合安装msxml3、4和6。我搜索了硬盘，发现周围没有其他msxml2的副本。

有没有人能帮我解决这个令人费解的问题？

编辑:只需设置一个简单的doc=new MSXML2.DOMDocument就足以导致错误。

Answer 1

现在很多库都是系统管理的。由于“真正的”库驻留在SxS缓存中，因此将内容转储到System32中只能做到这一点。

这就是为什么您想要对它们使用经过批准的部署技术的原因之一，对于MSXML，除非您简单地使用Microsoft规定的MSI包(或那些包装在EXE中的包)，否则这会变得有点复杂。MSXML4还提供了MSM和CAB格式的每个更新，这与只支持MSXML4的"SxS安装“(在MSXML6中被删除是一个坏主意)有更多的关系。

好消息是，除了Server2003之外，所有受支持的操作系统都已经包含了MSXML 6，因此将其作为目标，您就可以在家中自由地工作，不需要部署：

MSXML6 is now in-band, MSI setup headaches should now (almost) be gone..

MSXML3在大多数Windows版本上都可用，而且至少可以部署回Win98：Microsoft XML Parser (MSXML) 3.0

很长一段时间以来，安装、组件注册和服务并没有像你想象的那样工作。将应用程序打包为MSI包要比使用传统的脚本安装工具安全得多。不要试图部署像MDAC和MSXML这样的零星复杂的包。

您正在对哪个特定的MSXML版本进行早期绑定？请记住，如果您使用MSXML 4，这是特定于子版本(并非所有接口都是从service pack到service pack的二进制兼容)。

Answer 2

最好总是使用依赖于版本的ProgID，而不是独立于版本的ProgID。例如，我建议您改用Msxml2.DOMDocument.6.0。有关更多信息，请参阅Using the right version of MSXML in Internet Explorer。