在从 .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 的修补时，是否有任何最佳实践？
谢谢 ！
最好的问候弗兰克
您对生成的 Interop DLL 的理解非常正确 - 它基本上包含一堆元数据，这些元数据以 .NET 可以理解的术语描述 COM DLL。调用原始 XYZ 程序集，因此必须在目标系统上注册。
对于第二个问题，如果 COM DLL 支持您在应用程序中使用的相同接口，您的应用程序应该仍然可以工作 - 但是，由于您不会针对新 DLL 进行显式测试，因此存在引入错误的风险。这对于完全用非托管代码编写的应用程序来说是完全相同的，因此在这种情况下使用 .NET 不会引入更多复杂性。
第一个问题是直截了当的，它是一个包装器，而不是替代品。术语是 RCW，Runtime Callable Wrapper。
二是假设情况。一个简单的错误修复不会更改 COM 服务器的公开可见界面中的任何内容，除了验证更改没有破坏您的程序之外，您不需要任何操作。然而，在 COM 中，更改公共接口需要为接口和 coclass 使用新的 guid，这是一个冷酷的硬规则。这对于避免 DLL Hell 非常重要。因为这样的更改会导致很难检测到损坏，所以 AccessViolation 并不少见。你将没有像样的方法来解决这个问题。此类更改需要您再次运行 Tlbimp.exe，该 guid 是互操作库声明的一部分。并重新编译您的应用程序。