将激活上下文 API 与不同位置的许多 dll 一起使用
我在位置 A 中运行的 .Net 客户端中使用激活上下文 API，在 WS2008 上的位置 B（与 A 完全不同的位置，不是同一台计算机上的同级/后代等）中加载无注册的 COM 组件通过在 ACTCTX 中传递位置 B ，它工作正常。
但是，我现在需要对另一个 COM dll 执行相同的操作，而该 dll 又依赖于位于完全不同位置的几个 .Net COM 程序集。
我已将依赖的 .Net 程序集添加到清单中，并将清单和 COM dll 放在位置 B 中，但我必须将依赖的 .Net 程序集放在位置 A（客户端运行的位置）才能使其正常工作。实际上，它们将位于与位置 A 和位置 B 完全不同的目录中。
我尝试做的事情是否可能，即是否可以使用激活上下文 api 在不同的不相关目录中加载多个 COM 组件？
I am using Activation Context API in a .Net client running in a location A to load a COM component reg-free in location B (which is completely different location to A, not a sibling/descendent etc. on the same machine) on WS2008 by passing in location B in the ACTCTX and it works fine.
However, I now need to do the same thing with another COM dll which in turn has dependencies on a couple of .Net COM assemblies which live in completely different locations.
I have added the dependent .Net assemblies to the manifest and put the manifest and COM dll in location B but I have to put the dependent .Net assemblies in location A (where the client runs) to get it to work. In reality, they will live in completely different directories to location A and location B.
Is what I'm attempting to do possible, i.e. is it possible to load multiple COM components in different unrelated directories using activation context api?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
.NET 查看活动和进程激活上下文以发现无需注册的元数据（
.NET looks at the active and process activation contexts to discover reg-free metadata (
<clrClass>, etc) just like native COM does. Unlike native COM, however, it doesn't use the information contained in the activation context to determine the location of the actual files. There, I believe it looks only at the GAC, followed by locations of files next to the client EXE only. You can probably confirm this using Sysinternals Procmon. I'd imagine you could try the workarounds Hans suggested or pre-loading the needed assemblies manually into your process and see if that works; I didn't get to try this out as in my scenario the client exe was a native exe I didn't have control over.