Visual Studio - Register for COM interop

0
votes

In Visual Studio (C#), ticking 'Register for COM interop' updates the Windows environment such that my Visual Studio project, its dependent Visual Studio projects (in same solution) & dependent DLL files are all available for another COM-consuming application on the same machine. This COM-consuming application works with no issue.

If I want the same COM objects to be available to a consuming application on another machine, what must I do?

I assume I still build with the same flag set (so that the DLL files have COM content)? I assume I must register the COM DLL file (e.g. regasm) - Unfortunately this doesn't work - do I register every DLL file that I am constructing & every DLL file library they reference?

Please make no assumptions about my COM knowledge.

1
visual-studiocom
Ticking 'Register for com interop' does the exact equivalent of Regasm.exe yourlibrary.dll /tlb /codebase. "this doesnt work" can mean entirely too many things. - Hans Passant
equivalance suggests I only need to register one dll, the dll that exposes the interop interfaces, its dependancies must be transparently handled. when I do that on the 2nd m/c I get ActiveX Automation server cannot create object. this is suggesting VS is doing more than Regasm, because on the VS m/c the COM-consuming application does not complain. I'm trying to understand what is VS doing by setting the flag, so I can replicate it on another m/c without installing VS there. The dll is a library class, targeting .net framework, but primarly is a COM resource for a COM consumer. - Jean

1 Answers

1
votes

You don't quite provide enough information to answer with certainty, but there are enough hints to guess at what you are doing.

When your client app asks for the COM object, the .NET runtime is invoked and it locates the COM-exposing assembly DLL from the information stored by RegAsm (specifically by the /codebase parameter). But after that, it's all .NET assembly loading rules - including the loading of dependencies.

If your COM assembly has dependencies, the dependent assemblies must be locatable from the client process. It doesn't matter whether the dependencies are in the same folder as the COM DLL - the one loading those dependencies is the process, not your COM DLL. The .NET runtime uses a process called Fusion to decide where to look for .NET assemblies.

You have two practical choices:

  1. Put the COM DLL, its dependencies and the client EXE all in the same folder. This works if there is only one client, and you control the client (so, don't do this if the client is IIS, for example). It's the simplest solution.

  2. Give all the .NET components a strong name and deploy them to the GAC1. You still have to run RegAsm; but don't use the /codebase argument.

It is also possible to customize the Fusion rules by giving the client app a manifest with the proper entries, but that's too much of a hassle. The other options are more practical.

If this doesn't describe your problem, then I would use a combination of SysInternals' (now Microsoft's) Process Monitor and the .NET fusion log functionality to look into where the process is seeking the different DLLs.

1Technically you don't have to put the main COM DLL in the GAC, but it makes no sense to use /codebase for the COM DLL when you have to deal with GAC anyway. At that point you might as well put them all in the GAC