繁体   English   中英

免注册 COM 互操作和相关程序集

[英]Registration-Free COM Interop and Dependent Assemblies

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

从历史上看,我们只是使用注册表来使这些加载项(作为 COM 服务器)对应用程序可用。 但是,现在我们正在尝试使用免注册 COM 互操作来执行此操作。

我们希望这些插件能够与应用程序运行所在的目录分开存放在一个单独的目录中——最好是在任何地方。 但是,由于无法解析依赖程序集,我们显然遇到了服务器对象的实例化问题,这些程序集也存在于 COM 服务器 DLL 的目录中。

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

有谁知道如何让它工作? 目前尚不清楚我们是否可以在模块的 SxS 清单中识别依赖程序集,或者我们是否可以以不同的方式创建激活上下文?

感谢您的任何想法/提示!

杰夫

希望我能理解这个问题,因为我不太熟悉 MFC 项目,也不是它的限制条件。 一个“众所周知的”.NET 类有一个接口(在 MFC 应用程序中永久注册),然后处理所有的激活和实例化?

罗德尼

当我查看使用 ClickOnce 和免注册 COM 简化应用程序部署的文章时,我注意到它们在应用程序清单中引用了免注册 COM 对象 DLL 的文件名。 我猜这个文件名可以更改为包含目录等。

其次,在“更复杂的示例”一节中,它们包含依赖的 COM 对象作为对其项目的引用,并将它们设置为孤立的。 也就是说,他们现在也是免费注册的。 我的猜测是他们的路径也可以更新。

有几种方法可以解决这个问题。 第一步是确定失败的原因。 这需要使用fuslogvw收集 Fusion 日志。 使用此日志,查找无法加载的托管 COM 服务器和依赖程序集 - 我们需要了解加载服务器的上下文,这将告知我们依赖程序集失败的原因。

只要您能尽早获得事件,“总是”有效的大锤解决方案是AppDomain.AssemblyResolve

根据应用程序和 COM 服务器的相对布局,另一种选择是更新探测路径

您是否使用 .net 框架注册了中间(互操作)dll?

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

问候帕尼

打开您的 Visual Studio 命令提示符并尝试使用 regasm 注册您的程序集

regasm /tlb:"path"

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM