2

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?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Alex Hatcher
  • 21
  • 2
  • Try [isolated COM](http://qualapps.blogspot.com.au/2007/06/isolated-com.html?m=1) – noseratio Aug 29 '13 at 01:53
  • The interop assembly is *never* registered. Only the COM component that you interop with requires it. Use the vendor's recommended deployment procedure. – Hans Passant Aug 29 '13 at 12:52

2 Answers2

1

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:

enter image description here

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.

Community
  • 1
  • 1
noseratio
  • 59,932
  • 34
  • 208
  • 486
0

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.

Eric Lloyd
  • 509
  • 8
  • 19
  • At this stage we are simply generating a Web Deploy that we push directly to AWS Elastic Beanstalk. It's extremely simple and I'm trying to maintain the 'one click' aspect of it and continue to use Beanstalk as an app service and not actually dig into the instances directly. – Alex Hatcher Aug 28 '13 at 22:07
  • @EricLloyd, thanks. I still develop some unmanaged code, although most of it is consumed by "mother" .NET projects. Where possible, I prefer shaping it as a COM DLL rather than doing interop stuff in C#. – noseratio Aug 30 '13 at 10:23