I have a TLB that was provided as a part of a third-party API. I used TLBIMP.exe to generate a DLL assembly wrappper. However, at development time, it appears that the assembly
If the type library is also embedded with your 3rd party COM DLL as it should be, Isolated COM can indeed be used for this (you could verify that with OleView). Consuming a COM DLL this way is quite easy with VS2010/2012. The DLL has to be registered on the development machine. Then you'd just add it as a reference to your .NET project and turn on its Embed Interop Types
and Isolated
properties:
The interop assembly will be merged with the consuming .NET assembly, and you'd only need to make sure that the COM DLL, .NET assembly and generated .manifest files are copied together when deployed.
It's very important to take into account the COM apartment model of your client app. You should have no problems with an STA client. For MTA model though, the default typelib-based marshaller may not work for COM objects created by the isolated DLL (more on this here). If the DLL comes with COM proxy/stub code implemented, this should not be a problem either.
Sadly, no. Your target DLL is a COM DLL, and as such, must be registered on each box it's deployed to. The good news, assuming you're building an installation package for deployment, is that most installer toolsets worth their salt should support COM registration out of the box. Check your installer's documentation.
If you're deploying via xcopy
to a large number of boxes, I'd say it's time to rethink your strategy. The only comfort you might take in this is that a COM DLL only has to be registered once per box, per version deployed. But still, xcopy
installs are generally a bad idea these days.
UPDATE: I stand corrected -- I'm voting up Noseratio. Shows how little I pay attention to COM integration these days.