为什么在 C# 中实例化 COM 对象会引发异常

Question

我正在尝试在我用 C# (.net 4.7.2) 编写的测试程序中实例化一个在用 Borland C++ 编写的 x86 dll 中定义的 COM 对象。 COM dll（服务器）正在工作，我有一个也用 C++ Borland 编写的 Windows 服务，它可以使用它并从类中实例化一个 COM 对象（使用 CoCreateInstance）。该 dll 已注册，并且 InprocServer32 条目具有该 dll 的正确路径。 typelib 中不存在 coclass，只有接口（存在于 typelib 中）。我使用 TlbImp 创建了我在 c# 项目中引用的 dll:s。在项目中，目标平台设置为 x86。我尝试实例化对象的方式是：

var comType = Type.GetTypeFromProgID("ins.MyComType");
object comObj = Activator.CreateInstance(comType);

但是第二行给了我

“抛出异常：mscorlib.dll 中的‘System.IO.FileNotFoundException’” 带有消息'检索组件的 COM 类工厂 CLSID {C4363C5E-3831-46DF-8701-60C8D1B612BA} 失败，因为 以下错误：8007007e 找不到指定的模块。 （来自 HRESULT 的异常：0x8007007E）。”。

如果我尝试以管理员身份运行应用程序并不重要。我对几年前尝试过类似的事情有一个模糊的记忆，当时它确实有效。它可能在 Win 7 机器上（甚至可能是 32 位系统）。我试图在 DependencyWalker 中打开该项目，但我不确定我在看什么。我收到几个错误：

*错误：未找到至少一个必需的隐式或转发依赖项。 *错误：发现具有不同 CPU 类型的模块。 *错误：检测到循环依赖。 *警告：未找到至少一个延迟加载依赖模块。 *警告：由于延迟加载依赖模块中缺少导出功能，至少有一个模块存在未解析的导入。

有没有人知道它可能导致异常的原因是什么？或者如果我能得到一些关于如何深入研究dependencywalker的提示？我得到了一棵巨大的系统装配树，但我看不到任何明显的装配突出，尽管 DW 将它们中的许多称为 64 位。我的猜测是某个地方的一些依赖 dll（s）应该是 x86，但哪个（s）。我应该安装一个类似的 redist 东西才能让它工作吗？

最好的问候

/埃里克

Answer 1

您应该编写一个包含以下行的简单 VBScript：

set obj = CreateObject("ins.MyComType")
MsgBox TypeName(obj)

将文件命名为 test.vbs

执行命令：

c:\windows\syswow64\wscript.exe test.vbs

使用来自 syswow64 的版本可确保它使用 32 位版本的 wscript.exe，它可以实例化 32 位 COM 对象。 c:\windows\system32 中的版本只能在 DLL 中实例化 64 位进程内 COM 对象...您说您的对象是 32 位 COM DLL 服务器。

如果 vbscript 失败，则可能是对象不兼容自动化 - 实现 IDispatch。否则，您将收到一条错误消息，为什么它会失败。

如果成功，您将知道 C++ 端可能没有任何问题导致问题。您认为是这种情况……但是 Borland C++ 的运行时在哪里？一切都是静态链接的，还是其中一些是动态链接的？如果它是动态链接的，它在路径中的什么位置？可能是您拥有的 C++ 服务在其路径中有该库，因此当它加载您的 COM 对象时，该库是可用的。但是，当您尝试从 .NET 或 VBScript 等第三方加载时，库的路径就会显示出来。谁知道？我只是提出建议。

如果您使用 ProcMon，它可以查看问题所在。它将向您显示正在读取哪些注册表项以及正在尝试加载哪些文件。