TLB to managed .NET assembly without Regsrv32 at deploy time

Question

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 requires registration with regsvr32 to be used.

This isn't a problem at development time however; I am using managed instances in production and registering the DLL manually will be a pain if not impossible when I deploy. Is there a way to use the managed DLL assembly in a way that doesn't require the registration step during deployment?

I've been reading around the Internet and have found some literature on registration-free COM using an app.manifest. Could this be a viable solution?

Answer 1

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.

Answer 2

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.