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
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.