了解 .NET + COM互操作性
从 .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 必须始终存在于系统上才能进行调用？
第二个问题：假设我已经使用 TBIMP.EXE 创建了 interop.XYZ.DLL。在运行 .NET 应用程序的系统上，XYZ.DLL 文件已修补/更新。我的假设是，只要新修补的 XYZ.DLL 中提供相同的类/方法，我的应用程序仍然可以工作。还是我错了？当必须处理引用的互操作 DLL 的修补时，是否有任何最佳实践？
谢谢 ！
此致 坦率
I'm in need of help on understanding the architecture when calling COM/DLL's created with TLBIMP.EXE, from a .NET application. The scenario is:
I have a DLL called XYZ.DLL which contains methods, classes etc. I can now create a .NET wrapper around the XYZ.DLL and will get a Interop.XYZ.DLL which I can reference from my .NET application.
My first question is then: When I in my .NET application create a object from a class in the Interop.XYZ.DLL and call a method on that class, is the original XYZ.DLL called? As far as I understand the Interop.XYZ.DLL now works as a form of proxy class for the original XYZ.DLL and therefore the XYZ.DLL must always be present on the system for making the call happen?
Second question: Lets say I have create the interop.XYZ.DLL using TLBIMP.EXE. On the system where my .NET application is running, the XYZ.DLL file is patched/updated. My assumtion would be that my application will still work as long as the same classes/methods are avaible in the newly patched XYZ.DLL. Or am I wrong? Is there any best-practice when having to deal with this patching of referenced interop'ed DLL's?
Thanks !
Best Regards
Frank
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您对生成的 Interop DLL 的理解非常正确 - 它基本上包含一堆以 .NET 可以理解的术语描述 COM DLL 的元数据。原始的 XYZ 程序集被调用，因此必须在目标系统上注册。
对于第二个问题，只要 COM DLL 支持您在应用程序中使用的相同接口，您的应用程序应该仍然可以工作 - 但是，由于您没有针对新 DLL 进行显式测试，因此您可以运行引入错误的风险。这对于完全用非托管代码编写的应用程序来说是完全相同的，因此在这种情况下使用 .NET 不会引入任何更多的复杂性。
Your understanding of the generated Interop DLL is pretty much correct - it basically contains a bunch of metadata that describes the COM DLL in terms that .NET can understand. The original XYZ assembly is called, so must be registered on the target system.
For the second question, your application should still work provided the COM DLL supports the same interfaces you are using in your application - however, as you won't have explicitly tested against the new DLL, you run the risk of bugs being introduced. This would be the exactly the same for an application written entirely in unmanaged code, so you are not introducing any more complexity by using .NET for this scenario.
第一个问题很简单，它是一个包装器，而不是替代品。该术语是 RCW，运行时可调用包装器。
第二个是假设情况。一个简单的错误修复不会更改 COM 服务器的公开可见界面中的任何内容，除了验证更改不会破坏您的程序之外，您不需要执行任何操作。然而，COM 中的一条冷酷硬性规则是，公共接口的更改需要为接口和组件类使用新的 guid。这对于避免 DLL Hell 非常重要。由于此类更改可能会导致很难检测到损坏，因此 AccessViolation 并不罕见。您将没有合适的方法来解决此问题。此类更改需要您再次运行 Tlbimp.exe，guid 是互操作库声明的一部分。并重新编译您的应用程序。
The first question is straight forward, it is a wrapper, not a replacement. The term is RCW, Runtime Callable Wrapper.
The second is a what-if situation. A simple bug fix that doesn't change anything in the publicly visible interface of the COM server doesn't require any action on your end beyond verifying that the change didn't break your program. It is however a stone cold hard rule in COM that a change in a public interface requires using a new guid for the interface and the coclass. This is very important to avoid DLL Hell. Because such a change can cause very hard to detect breakage, an AccessViolation is not uncommon. You will have no decent way to troubleshoot this. Such a change requires that you run Tlbimp.exe again, the guids are part of the interop library declaration. And recompile your app.