【问题标题】:Using Activation Context API with many dlls in different locations在不同位置使用带有许多 dll 的 Activation Context API
【发布时间】:2011-09-15 10:35:35
【问题描述】:

我在位置 A 运行的 .Net 客户端中使用 Activation Context API 在位置 B 中加载无 reg 的 COM 组件(与 A 完全不同的位置,而不是同一台机器上的兄弟/后代等) ) 在 WS2008 上通过在 ACTCTX 中的位置 B 传递,它工作正常。

但是,我现在需要对另一个 COM dll 执行相同的操作,而后者又依赖于位于完全不同位置的几个 .Net COM 程序集。

我已将依赖的 .Net 程序集添加到清单中,并将清单和 COM dll 放在位置 B,但我必须将依赖的 .Net 程序集放在位置 A(客户端运行的位置)以使其工作。实际上,他们将生活在与位置 A 和位置 B 完全不同的目录中。

我正在尝试做的事情是否可行,即是否可以使用激活上下文 api 在不同的不相关目录中加载多个 COM 组件?

【问题讨论】:

  • 非常怀疑,激活上下文中唯一的 .NET 意识是清单中的 <clrClass> 元素。听起来好像不适用。 GAC 或 AppDomain.AssemblyResolve 是解决方法。在 regfree COM 中不使用本地部署通常是一个错误。
  • 甚至可以在同一个目录下完成吗?
  • 您可以附加到应用程序域的 AssemblyResolve 事件并按需加载 dll,无论从哪个位置

标签: com side-by-side regfreecom activation-context-api


【解决方案1】:

.NET 像本机 COM 一样查看活动和进程激活上下文以发现无注册元数据(<clrClass> 等)。然而,与原生 COM 不同的是,它不使用激活上下文中包含的信息来确定实际文件的位置。在那里,我相信它只查看 GAC,然后仅查看客户端 EXE 旁边的文件位置。您可能可以使用 Sysinternals Procmon 确认这一点。我想您可以尝试 Hans 建议的解决方法或手动将所需的程序集预加载到您的流程中,看看是否可行;我没有尝试过,因为在我的场景中,客户端 exe 是我无法控制的本机 exe。

【讨论】:

  • 您确定 .NET 查看进程默认激活上下文吗?如果我创建一个激活上下文并将其设置为进程默认值,然后我激活第二个激活上下文(即使第二个为空),我无法实例化其<clsClass> 位于第一个激活上下文中的对象。普通的Assembly.Load 工作正常。
  • 关于我的评论:看起来这是 .NET 中缺少的功能(激活第二个激活上下文会隐藏进程默认激活上下文)。 connect.microsoft.com/VisualStudio/feedback/details/766699/…
猜你喜欢
  • 2011-02-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-06-13
  • 1970-01-01
  • 2014-05-30
  • 2020-07-20
  • 1970-01-01
相关资源
最近更新 更多