TLB to managed .NET assembly without Regsrv32 at deploy time

跟風遠走 提交于 2019-12-02 00:10:58
noseratio

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!