如何使一种类型在一个 AppDomain 中已知,但在另一个 AppDomain 中未知?

发布于 2024-08-15 01:53:39 字数 765 浏览 2 评论 0原文

我的问题很简单。出于单元测试的目的,我需要一个从 Exception 类型派生的静态编译类型,该类型在一个 AppDomain 中已知,但在另一个 AppDomain 中未知。

一个简单的解决方案是:

  1. 在应用程序可执行文件的目录下创建一个子文件夹。
  2. 在那里放置一个具有某种异常派生类型的程序集。
  3. 更新 app.config 文件,将此文件夹添加到探测路径。
  4. 创建一个新的 AppDomain,但 app.config 略有不同 - 没有该元素。

现在,主 AppDomain 可以轻松加载该类型,因为它的位置位于探测路径中,但第二个 AppDomain 不能 - 任务已完成。

但此方法需要:

  • 一个附加文件
  • 夹 一个虚拟程序集
  • 一个虚拟应用程序配置文件

我想知道是否可以更简单地实现我的目标,但无需 Reflection.Emit。

谢谢。

编辑:

任何异常派生类型都可以。

动机:

我们有一个分布式应用程序,由客户端、服务器和代理组成。有些程序集专门在代理上找到,有些程序集专门在服务器上找到。服务器和代理在部署新功能后都可以进行扩展。问题是,某些操作可能会因异常而失败,而接收端未知哪种类型。我正在开发一个工具来应对这种情况,并希望现在对其进行单元测试。为此,我需要模拟一种情况,即远程站点上引发的异常的类型在接收端未知。

My question is simple. For unit test purposes, I need a statically compiled type deriving from the Exception type, which is known in one AppDomain, but unknown in another.

A straightforward solution would be:

  1. To create a subfolder under the directory of the application executable.
  2. Place there an assembly with some Exception derived type.
  3. Update the app.config file, adding this folder to the probing path.
  4. Create a new AppDomain, but with a slightly different app.config - without the element.

Now, the main AppDomain can load the type easily, because its location is in the probing path, but the second AppDomain cannot - mission accomplished.

But this method requires:

  • An additional folder
  • A dummy assembly
  • A dummy app config file

I am wondering if I can achieve my goal simpler, but without Reflection.Emit.

Thanks.

EDIT:

Any Exception derived type will do.

Motivation:

We have a distributed application, consisting of clients, the server and agents. There are assemblies found exclusively on agents and there are some found exclusively on the server. Both the server and agents can be extended after being deployed with new features. The thing is that it is possible that some action will fail with an exception, which type is unknown on the receiving end. I am developing a facility to cope with this situation and wish to unit test it now. For that I need to simulate a situation where an exception raised on a remote site is of a type unknown on the receiving end.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

新人笑 2024-08-22 01:53:39

首先,我不知道有什么方法可以防止从已加载的程序集中加载类型。这意味着我们需要谈论程序集,而不是类型。即使某种类型在第一次访问之前不会被初始化,但如果加载了具有您的类型的程序集后会访问该类型,则无法使 CLR 忘记它。

换句话说,你必须有一个具有受保护类型的单独的 dll。其余部分可以通过多种方式解决,即您可以在需要的 appdomain 中使用 Assembly.LoadFrom 加载程序集,而不是使用 appconfig。

这有多好,取决于您到底想在这里做什么。

First of all I am not aware of any way to prevent loading a type from a loaded assembly. Which mean that we need to talk assemblies - not types. Even though a certain type is not initialized until it is accessed the first time, if it will be accessed if the assembly with your type is loaded you cannot make the CLR unlearn it.

In other words you have to have a separate dll with the protected type. The rest of it can be addressed in a number of ways, i.e. instead of playing with appconfig you can load the assembly with Assembly.LoadFrom in the appdomain where you need it.

How much better this is, is for you to decide depending on what exactly you are trying to do here.

儭儭莪哋寶赑 2024-08-22 01:53:39

AppDomain.CreateDomain 具有接受 AppDomainSetup 的重载。此类的许多属性与 .config 文件中的相应条目匹配。包括 PrivateBinPath。 ApplicationBase 设置 CLR 开始搜索的“主”目录。

AppDomain.CreateDomain has overloads that accepts a AppDomainSetup. Many of the properties of this class match a corresponding entry in a .config file. Including PrivateBinPath. ApplicationBase set the "home" directory where the CLR starts searching.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文