Registration-Free COM Interop and Dependent Assemblies

Question

We are working on an integration of a large MFC-based application with a handful of managed (.NET) add-ins. Communication with these add-ins is done via COM.

Historically, we've just used the registry to make these add-ins available (as COM servers) to the application. But, now we're trying to use registration-free COM interop to do this.

We'd like these add-ins to be able to live in a separate directory from the one that the application is running in -- ideally anywhere. But, we're apparently running into problems with the instantiation of the server objects due to the inability to resolve dependent assemblies, which also live in the directory with the COM server DLL.

"Old-fashioned" COM interop handled this by using a LoadFrom context when it loaded the target assembly. But the activation context mechanism doesn't seem to do this.

Does anyone know how to get this to work? It's not clear whether we can identify dependent assemblies in the module's SxS manifest, or perhaps we can create the activation context differently?

Thanks for any thoughts/tips!

Jeff

Answer 1

open your visual studio command prompt and try to register your assembly using regasm

regasm /tlb:"path"

Answer 2

Have you registered intermediated (interop) dlls with .net framework?

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm "path..\AxInterop.xxx.dll" or C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm "path..\Interop.xxx.dll"

Regards Phani

Answer 3

When I look at the article at Simplify App Deployment with ClickOnce and Registration-Free COM I note that they reference the filename of the registration free COM object DLL in the application manifest. I'm guessing that this filename could be changed to include a directory or such.

Secondly, in the section "A More Complex Example", they include dependent COM objects as references to their project and sets them as isolated. That is, they are now also registration free. My guess is that their path could also be updated.

Answer 4

There are a few ways to possibly solve this. The first step though is to determine why it is failing. This requires collecting a Fusion log with fuslogvw. Using this log, look for the managed COM server and the dependent assembly that is failing to load - we need to understand the context in which the server is loaded and that will inform us as to why the dependent assembly failed.

The big hammer solution that will "always" work, as long as you can get the event early enough, is AppDomain.AssemblyResolve.

Another option, depending on the relative layout of the application and COM server is to update your probing paths.

Answer 5

Hope I understand the issue as I'm not so familiar with an MFC project nor it's constraints. How about a "well-known" .NET class with an interface (permanently registered with the MFC app) that, in turn, handles all the activating and instantiating?

Rodney