COM 异常 - TYPE_E_CANTLOADLIBRARY？答案

【问题标题】：COM Exception - TYPE_E_CANTLOADLIBRARY?COM 异常 - TYPE_E_CANTLOADLIBRARY？
【发布时间】：2011-08-08 00:23:54
【问题描述】：

我在我的 .Net Web 应用程序中使用了 COM dll。这适用于多台不同的机器。
但是在一台特定的机器上，我收到以下错误：

无法将“CServer.CApplicationClass”类型的 COM 对象转换为接口类型“CServer.ICApplication”。此操作失败，因为 IID 为“{CF0DFA28-046B-4C7D-8AA9-F4B7477D8CAE}”的接口的 COM 组件上的 QueryInterface 调用因以下错误而失败：加载类型库/DLL 时出错。（来自 HRESULT 的异常：0x80029C4A (TYPE_E_CANTLOADLIBRARY)）。

我已经使用regsvr32 命令注册了 dll。
我还为这个 dll 创建了一个 COM+ 应用程序。通过注册表运行搜索
我可以在很多地方找到钥匙。我还尝试注销 dll 并删除计算机上对该 dll 的所有引用。然后重新添加dll并重新注册。

我编写了一个简单的 windows 脚本文件来测试 dll。这工作正常。但是问题存在于我在 iis 中运行的 .net 项目中。

谁能帮我解决这个问题？..

如果您需要更多信息，请发表评论。谢谢。

【问题讨论】：

你的服务器是什么？ x64/x86？您的应用程序池设置为什么？ COM 程序集是为什么而构建的？
windows 7 Professional 64 位..应用程序池设置为应用程序池设置为 .NET Framework v2.0.50727。 COM 程序集的构建允许我的应用程序访问\调用一些用 delphi 编写的遗留代码。
这是您安装的第一个 64 位服务器吗？
应用程序池用户是否具有对注册表和 COM 服务器激活所需文件的读取权限？
不，这不是我安装的第一个 64 位服务器，是的，应用程序池用户具有读取权限。

标签： asp.net exception com registry

【解决方案1】：

我遇到了类似的问题，“TYPE_E_CANTLOADLIBRARY”消息。

背景： 我有一个使用 Interop.ReferenceA.dll 的项目。该文件是使用 tlbimp ReferenceA.dll /out: Interop.ReferenceA.dll 创建的。

解决方案： 当我使用 RegDllView 查看 ReferenceA.dll 时，我注意到 ReferenceA.dll 有一个子类，即错误消息中显示的 IID。我查看了子类的源代码，发现它依赖于 Interop.ReferenceB.dll。

事实证明，子类需要 Interop.ReferenceB 作为类型库才能工作。所以我运行了这个：

regasm /tlb:Interop.ReferenceB.tlb Interop.ReferenceB.dll（使用了 32 位版本的 regasm。）

错误消失了。

【讨论】：

【解决方案2】：

确保您的 AppPool 设置为 x86。还要确保您的程序集仅针对 x86。

【讨论】：

您的意思是允许应用程序池启用 32 位应用程序吗？

【解决方案3】：

我遇到了类似的问题。首先得到拒绝访问，经过一番环顾后解决了，只是遇到了这个错误消息（TYPE_E_CANTLOADLIBRARY）。请注意，我正在 Windows 7 上运行 COM+ 组件。

在一些涉及弄乱注册表的尝试无果后，我和我的同事找到了一种启动和运行它的方法：

1) 注销您的 dll (regsvr32 -u dllname)

2) 确保您对 dll 的引用已从注册表中清除（首先备份）

3) 在组件服务中创建一个空的 com+ 应用程序（服务器应用程序）

4) 将应用程序 id 复制到剪贴板

5) 转到“c:\program files (x86)\Complus applications”并在剪贴板上创建一个带有 id 的文件夹

6) 将您的 dll 复制到该文件夹并注册它

7) 返回您的组件服务并将组件添加到您使用“c:\program files (x86)\Complus applications{*app id*}”上的 dll 创建的应用程序中

那是为我做的。希望对您有所帮助。

【讨论】：

【解决方案4】：

我遇到了类似的问题，错误是在我的电脑上触发的，但在其他开发人员的电脑上却没有。

事实证明，我一直在我的 PC 上测试一个自动构建过程，该过程更新了程序集的版本号，因此在注册表中注册的 TLB 的版本号高于我们通常使用的版本号。

在尝试获取接口时，服务器一直在使用错误的 TLB 信息，从而导致错误的程序集。一旦我在注册表中删除了更高版本的条目，它就可以正常工作了。

现在我们只需要确保构建过程不会再次导致该问题。 :)

【讨论】：