Registration-Free COM Interop and Dependent Assemblies

Question

Hi folks -

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

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

Answer 2

Hi,

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

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

regasm /tlb:"path"