什么可能导致Vb6运行时错误430

Question

我有一个用vb6编写的COM dll。当我尝试从此dll创建类模块的新对象时，我得到一个运行计时器错误430：类不支持自动化或不支持预期的接口。有趣的是，这只发生在IDE外部，当我在IDE中进行调试时，没有抛出错误，并且成功创建了类的新对象。可能是什么原因？

一般情况下，我偶尔会在COM dll中遇到这些错误。调试COM问题的最佳方法是什么？如何知道程序运行时使用的dll的路径？

Answer 1

如果这个项目完全在VB6中。可能的原因是EXE在其目录中有一个DLL二进制文件的副本。当你开火时，它使用该副本而不是编译副本。当您添加EXE与旧DLL不兼容的方法或类时。如果你做了一个错误修复或只是使用内部代码，那么EXE将运行但它使用旧的DLL。

将DLL设置为二进制兼容性。 确保您有一个Compatible目录。 把Last版本的DLL放在那里。 将二进制兼容性指向该DLL。 确保您的EXE编译到它的项目目录。 从它的项目目录运行EXE。这样它将使用您编译的DLL。 您需要编写一个实用程序，以便可以单独编译每个项目。 使用Virtual PC或其他计算机测试您的设置。

所有这些步骤都有助于避免DLL Hell。我自己的项目有6个层次的二十多个ActiveX项目。当我采用上面的我的DLL地狱问题几乎没有。

Answer 2

兼容读取二进制vs项目。

如果你有一个共享dll，你必须小心并兼容使用二进制文件。这样VB6将在构建之间保持相同的COM签名/接口。你必须有一个已发布的DLL的副本供VB6比较 - 我通常有一个单独的文件夹用于发布的二进制文件。具有二进制兼容性的限制是您无法删除公共属性或方法，也无法更改其签名。您可以添加新属性和方法。

如果必须进行重大更改（例如删除旧的公共方法），请使用项目兼容性 - 但是，如果这样做，则必须重新编译使用共享DLL的所有其他应用程序。

Answer 3

这几乎肯定是一个版本问题，有时被称为“DLL地狱”。

背景是.NET世界被明确设计为允许接口在保持相同名称的同时发展。但是在COM世界中，接口被认为是不可变的。

当您在IDE中工作时，Visual Studio每次运行解决方案时都会为COM dll创建一个新的COM Interop包装器。但除非您每次都发布并替换整个解决方案，包括全新的COM Interop包装器，否则您将遇到版本问题，其中.NET代码需要一个COM接口，但看到的却是另一个。

编辑：出于某种原因，我假设您正在尝试使用.NET组件中的COM组件。如果整个解决方案实际上是VB6，那么Conley先生的解决方案是推荐的方法。讨论问题的Here's a good link。