Understanding .NET + COM interoperability

Question

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

Answer 1

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.

Answer 2

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.