使用激活上下文API与许多dll在不同的位置 [英] Using Activation Context API with many dlls in different locations

查看:219
本文介绍了使用激活上下文API与许多dll在不同的位置的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在运行在位置A的.Net客户端中使用Activation Context API在位置B(它与A完全不同的位置,而不是同一机器上的兄弟/子孙等)上注册了一个COM组件)在WS2008通过传递在位置B在ACTCTX和它的工作正常。

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.

然而,我现在需要做同样的事情与另一个COM dll依次有依赖在几个.Net COM组件,生活在完全不同的位置。

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.

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

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.

是我试图做的可能,也就是可以加载多个COM组件在不同的不相关目录中使用激活上下文api?

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?

推荐答案

.NET查看活动和进程激活上下文以发现reg-元数据(< clrClass> 等),就像本地COM一样。与本地COM不同,它不使用激活上下文中包含的信息来确定实际文件的位置。在那里,我相信它只看GAC,其次是客户端EXE旁边的文件的位置。你可以使用Sysinternals Procmon来确认。我想象你可以尝试的解决方法汉斯建议或预先加载所需的程序集到你的过程,看看是否有效;我没有得到尝试这个,因为在我的方案客户端exe是一个本机exe我没有控制。

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

这篇关于使用激活上下文API与许多dll在不同的位置的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆