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