不同的依赖解析行为在默认AppDomain与新AppDomain中加载程序集 [英] Different dependency resolution behavior loading assembly in default AppDomain vs new AppDomain

问题描述

我一直在通过C ++ / CLI查看与单元测试和托管/本地互操作相关的问题。细节不重要，所以我不会填充他们，除非问，但情况可以蒸馏如下：

I've been looking at an issue related to unit testing and managed/native interop via C++/CLI. The details aren't important so I won't fill them in unless asked, but the situation can be distilled as follows:

两个程序集，称为Lib和Dep，存在于同一目录下，调用它D. Lib通过装配引用依赖于Dep。我们正在运行在一个不同的，不相关的目录中的应用程序。应用程序创建一个新的AppDomain，将ApplicationBase设置为目录D，加载Lib汇编，并尝试通过反射构造一个类型。

Two assemblies, call them Lib and Dep, exist in the same directory, call it D. Lib depends on Dep via an assembly reference. We are running in an application that lives in a different, unrelated directory. The application creates a new AppDomain with ApplicationBase set to directory D, loads the Lib assembly, and tries to construct a type in it via reflection.

作为Lib的模块构造函数的一部分我们转换到默认AppDomain并加载引用的程序集Dep。因为默认的AppDomain的ApplicationBase不是目录D，所以Dep不能被解析，抛出一个FileNotFoundException，并且加载Lib程序集失败。

As part of Lib's module constructor we transition into the default AppDomain and load the referenced assembly Dep. Because the default AppDomain's ApplicationBase is NOT directory D, Dep cannot be resolved, a FileNotFoundException is thrown, and loading the Lib assembly fails.

这一切都有意义 - 它可能是，我们试图加载一个程序集不是在当前的AppDomain的程序集解析路径，并且失败。

This all makes sense -- convoluted as it may be, we tried to load an assembly that's not on the assembly resolution path for the current AppDomain, and failed.

但是如果我运行这个整个过程在默认AppDomain而不是创建一个新的AppDomain，没有失败。即使通过目录D不是ApplicationBase，lib程序集被加载，实例化其中一个类的代码正确运行。模块构造函数代码仍然应该在默认的AppDomain中运行，虽然它不需要转换到它。

BUT if I run this whole process in the default AppDomain instead of creating a new AppDomain, there is no failure. Even through directory D is not the ApplicationBase, the Lib assembly is loaded and the code instantiating one of its classes runs correctly. The module constructor code should still be run in the default AppDomain although it does not need to transition to it.

在我看来，第二种情况应该失败，第一。这两种情况之间的程序集引用解析过程有什么不同？

It seems to me that the second case should fail just like the first one. What's different about the assembly reference resolution process between these two cases?

推荐答案

完整阅读 MSDN页面运行时如何查找程序集比我之前做过的。最后一部分其他已探测的位置概述了当解析正在加载的程序集的引用时，加载的程序集的位置被作为提示可以找到引用程序集的位置。

OK, I found what I was missing before via a more complete reading of the MSDN page "How the Runtime Locates Assemblies" than I'd done before. The very last section, "Other Locations Probed" outlines that when resolving references for an assembly being loaded, the loaded assembly's location is taken as a hint for where the referenced assembly can be found.

根据我看到的行为，我认为我们可以推断提示信息是AppDomain特定的，这样在AppDomain之外的提示不会被触发原始的程序集加载。

Based on the behavior I'm seeing I think we can extrapolate that the hint information is AppDomain-specific, such that the hint is not taken into account outside the AppDomain that triggered the original assembly load.

我使用我的测试项目验证了这一点 - 如果引用的程序集不切换到默认AppDomain，那么它会正确加载。所以这不是默认AppDomain的特殊行为，而是AppDomain的一般行为约束。

I verified this with my test project -- if the referenced assembly does not switch into the default AppDomain then it loads correctly. So this is not default AppDomain special behavior, it's general AppDomain constrained behavior.

这篇关于不同的依赖解析行为在默认AppDomain与新AppDomain中加载程序集的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！