了解.NET + COM互操作性

Question

从.NET应用程序调用使用TLBIMP.EXE创建的COM / DLL时，我需要帮助理解体系结构。场景是：

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

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

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

谢谢！

最诚挚的问候 弗兰克

Answer 1

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

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

Answer 2

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

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