了解 .NET + COM 互操作性答案

【问题标题】：Understanding .NET + COM interoperability了解 .NET + COM 互操作性
【发布时间】：2011-06-15 01:36:42
【问题描述】：

在从 .NET 应用程序调用使用 TLBIMP.EXE 创建的 COM/DLL 时，我需要了解架构方面的帮助。场景是：

我有一个名为 XYZ.DLL 的 DLL，其中包含方法、类等。我现在可以围绕 XYZ.DLL 创建一个 .NET 包装器，并将获得一个可以从我的 .NET 应用程序引用的 Interop.XYZ.DLL。

我的第一个问题是：当我在我的 .NET 应用程序中从 Interop.XYZ.DLL 中的类创建对象并调用该类的方法时，是否调用了原始 XYZ.DLL？据我了解，Interop.XYZ.DLL 现在可以作为原始 XYZ.DLL 的代理类的一种形式，因此 XYZ.DLL 必须始终存在于系统上才能进行调用？

第二个问题：假设我使用 TLBIMP.EXE 创建了 interop.XYZ.DLL。在我的 .NET 应用程序运行的系统上，XYZ.DLL 文件被修补/更新。我的假设是，只要在新修补的 XYZ.DLL 中提供相同的类/方法，我的应用程序仍然可以工作。还是我错了？在处理引用的互操作 DLL 的补丁时，是否有任何最佳实践？

谢谢！

最好的问候弗兰克

【问题讨论】：

标签： .net com interop tlbimp

【解决方案1】：

第一个问题是直截了当的，它是一个包装器，而不是替代品。术语是 RCW，Runtime Callable Wrapper。

第二个是假设情况。一个简单的错误修复不会更改 COM 服务器的公开可见界面中的任何内容，除了验证更改没有破坏您的程序之外，您不需要任何操作。然而，在 COM 中，更改公共接口需要为接口和 coclass 使用新的 guid，这是一个冷酷的硬规则。这对于避免 DLL Hell 非常重要。由于此类更改可能导致非常难以检测到破损，因此 AccessViolation 并不少见。您将没有像样的方法来解决此问题。此类更改需要您再次运行 Tlbimp.exe，该 guid 是互操作库声明的一部分。并重新编译您的应用程序。

【讨论】：

【解决方案2】：

您对生成的 Interop DLL 的理解非常正确 - 它基本上包含一堆元数据，这些元数据以 .NET 可以理解的术语描述 COM DLL。调用原始的 XYZ 程序集，因此必须在目标系统上注册。

对于第二个问题，如果 COM DLL 支持您在应用程序中使用的相同接口，您的应用程序应该仍然可以工作 - 但是，由于您不会针对新 DLL 进行显式测试，您冒着引入错误的风险。这对于完全用非托管代码编写的应用程序来说是完全一样的，因此在这种情况下使用 .NET 不会引入更多复杂性。

【讨论】：