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

Comfit

Did you find a solution to that`? – Sharmainesharman

Answer 1

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

Crus

This is actually a workaround that has been successful: we create a C++/CLI module, which CAN be activated in a registration-free manner, and we use it to instantiate the C# class. In order for this to work, we also need to setup an AssemblyResolve event handler, so that dependent assemblies in the same directory can be located. This is OK, but is kind of clunky. It seems that this should be able to work without this extra level of indirection. – Comfit

Answer 2

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.

Bipod

We don't really have the luxury of modifying the application manifest, as the assemblies being loaded here are "add-ins", and can be added after the fact. It's possible that doing something more in the module manifest would be the answer here, but nothing that we've tried has worked -- it appears to be "just" a problem with .NET's loading algorithms. – Comfit

Answer 3

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.

Sophist

Answer 4

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

Lipetsk

Thanks for the comment, Phani. The whole point of trying to do this is to avoid registration. – Comfit

Answer 5

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

regasm /tlb:"path"

Champion

As I mention above, we don't want to register anything. This would include the type library. Plus, in this case, the type library for the interface we're implementing is actually already registered. – Comfit