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
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With