3种绑定上下文是什么？
我知道有3种不同的绑定上下文或加载上下文：
Load LoadFrom LoadNeither - 什么是负载上下文？
- 它们适用于什么？
- 为什么assembly加载如此复杂？
- 在“LoadNeither”中，“既不”又是什么？
提前致谢…
—————以下是我最近发现的一些有用的引文——————–
理解上下文
没有解决加载器上下文及其存在的原因，没有关于Binder的文章是完整的。 装载机环境通常是混乱的根源。 将加载器上下文视为包含程序集的应用程序域中的逻辑存储区。 根据程序集的加载方式，它们属于三个加载程序上下文之一。
加载上下文简单地说，使用Assembly.Load加载的GAC，ApplicationBase或ApplicationBase下的PrivateBinPath中存在的所有程序集都将加载到Load上下文中。 使用AssemblyResolve事件解析的程序集也属于此类别。
LoadFrom上下文如果您尝试通过提供ApplicationBase外部的特定路径来加载程序集，并且在Load上下文中找不到程序集，则会在LoadFrom上下文中加载程序集。
这两个上下文如果您尝试使用Assembly.LoadFile（），Assembly.Load（byte []）或Reflection.Emit加载程序集，那些程序集将加载到Neither上下文中。
对于加载到LoadFrom上下文中的程序集，Binder首先检查Load上下文中是否已存在确切的程序集（相同的标识和位置）。 如果是，它将丢弃LoadFrom上下文中的程序集信息，并使用Load上下文中的程序集信息。 在确定它是否是同一个组件时，位置信息很重要，我们将很快介绍。 在.NET Framework 1.1中，这被称为LoadFrom的第二个绑定，因为Binder用于执行两个步骤 – 首先将程序集放在LoadFrom上下文中，然后如果找到匹配的程序集标识，则将其提升到Load上下文。 Load上下文中的位置。
确保尽可能将程序集加载到Load上下文中。 为此，程序集应该可以从AppDomain的GAC，ApplicationBase或PrivateBinPath中找到。 加载到此上下文中的程序集会自动获得NGen的好处，并自动获取此上下文中存在的程序集依赖项。
将程序集加载到LoadFrom上下文中有其自身的优点 – 它允许通过指定其路径来加载ApplicationBase外部的多个程序集。
现在，让我们谈谈组件的位置，同时确定通过LoadFrom（）加载的组件是否与通过Load（）加载的组件相同。 即使两个程序集中的类型相同，如果从不同的路径加载两个程序集，就加载器上下文而言，它们也不被认为是相同的。 这导致在同一应用程序域中重复加载相同程序集但在不同上下文中（Load和LoadFrom）并且Load上下文中程序集中的类型不允许在LoadFrom上下文中使用相同类型的情况（就assembly标识而言，即使它们是相同的组件也是如此）。 这是LoadFrom的缺点之一。 此外，LoadFrom上下文中的程序集不会自动获得NGen的好处。
对于Neither上下文，除非应用程序订阅AssemblyResolve事件，否则不能绑定此上下文中的程序集。 通常应该避免这种情况。
那么为什么CLR首先会有加载器上下文呢？ Loader上下文有助于确保加载程序集时的加载顺序独立性。 此外，它们在将程序集加载到不同的上下文时提供对程序集及其依赖项的隔离度量。
– 从了解CLR活页夹
可能只有少数人能够回答问题的“原因”部分。 加载上下文主要与依赖关系的绑定有关。 我的理解是：
- 使用“传统”位置和绑定方法
Load，将程序集加载到AppDomain。 加载的程序集可以用作Load上下文中加载的后续程序集的依赖项。 -
LoadFrom将程序集加载到AppDomain查找依赖项，如Load但有一点不同：这些程序集不会用于解析Load上下文程序集的依赖关系。 -
LoadNeither仅加载一个程序集。 如果它具有未解析的依赖项，则需要通过AssemblyResolve事件自行解决它们。
这是一个很棒的博客： http ： //blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx