I am a bit unhappy with what I see of .NET interop, particularly on the COM side. I expect to be able to load an arbitrary COM object that supports an interface. Since the interface is the contract, I shouldn’t need to know where the object came from (it may even have been created after my code was compiled) and the interface is the contract.<\/p>\n
The same should apply to native code loaded at runtime. I expect to be able to pick an arbitrary DLL by name, load that code into my process and as long as there’s a named entry-point and a (often implied) contract about the signature of the function behind that entry-point everything should work.<\/p>\n
The most obvious interop mechanisms I’m seeing take the name of the DLL that is being loaded as part of the binding. There may be a way to opt out on that (aside from the obvious one of writing the load-up code in C++ or COM and handling the runtime \u00a0load from there) and I will keep looking. So far I’m a bit underwhelmed though.<\/p>\n","protected":false},"excerpt":{"rendered":"
I am a bit unhappy with what I see of .NET interop, particularly on the COM side. I expect to be able to load an arbitrary COM object that supports an interface. Since the interface is the contract, I shouldn’t need to know where the object came from (it may even have been created after … Continue reading A Bit Unhappy with .NET Interop Dynamic Loading.<\/span>