免注册COM互操作和相关程序集 [英] Registration-Free COM Interop and Dependent Assemblies

问题描述

我们正在努力将基于MFC的大型应用程序与少数托管(.NET)加载项进行集成.与这些加载项的通信是通过COM完成的.

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.

从历史上看，我们只是使用注册表使这些加载项(作为COM服务器)可用于该应用程序.但是，现在，我们正在尝试使用免注册的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.

我们希望这些加载项能够存在于与应用程序运行所在的目录不同的目录中-理想情况是在任何地方.但是，由于无法解析依赖的程序集，我们显然在服务器对象的实例化方面遇到了问题，这些程序集也存在于COM服务器DLL的目录中.

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.

老式" COM互操作程序在加载目标程序集时通过使用LoadFrom上下文来解决此问题.但是激活上下文机制似乎没有做到这一点.

"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.

有人知道如何使它工作吗?尚不清楚我们是否可以在模块的SxS清单中识别依赖程序集，还是可以以不同的方式创建激活上下文?

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!

杰夫

推荐答案

希望我了解这个问题，因为我对MFC项目不太熟悉，也不是它的约束.带有接口(已在MFC应用程序中永久注册)并处理所有激活和实例化的".NET"类怎么样?

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?

罗德尼

这篇关于免注册COM互操作和相关程序集的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！