我知道有3种不同的绑定上下文或加载上下文：
Load
LoadFrom
LoadNeither
提前致谢...
---------------以下是我最近发现的一些有用的引文--------------------
了解情境
没有解决加载器上下文及其存在的原因，没有关于Binder的文章是完整的。装载机环境通常是混乱的根源。将加载器上下文视为包含程序集的应用程序域中的逻辑存储区。根据程序集的加载方式，它们属于三个加载器上下文之一。
加载上下文简单地说，将加载使用Assembly.Load加载的GAC，ApplicationBase或ApplicationBase下的PrivateBinPath中存在的所有程序集在Load上下文中。使用AssemblyResolve事件解析的程序集也属于此类别。
LoadFrom context 如果您尝试通过提供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上下文中。为此，程序集应该可以从AppDomain的GAC，ApplicationBase或PrivateBinPath中找到。加载到此上下文中的程序集会自动获得NGen的好处，并自动获取此上下文中存在的程序集依赖项。
将程序集加载到LoadFrom上下文中有其自身的优点 - 它允许通过指定其路径来加载ApplicationBase外部的多个程序集。
现在，让我们谈谈程序集的位置，同时确定通过LoadFrom（）加载的程序集是否与通过Load（）加载的程序集相同。即使两个程序集中的类型相同，如果两个程序集是从不同的路径加载的，就加载器上下文而言，它们也不被认为是相同的。这导致在同一应用程序域中重复加载相同程序集但在不同上下文（Load和LoadFrom）中加载相同程序集的情况，并且在LoadFrom上下文中不允许加载上下文中程序集中的类型相同（就装配身份而言，即使它们是相同的组件也是如此）。这是LoadFrom的缺点之一。此外，LoadFrom上下文中的程序集不会自动获得NGen的好处。
对于Neither上下文，除非应用程序订阅AssemblyResolve事件，否则不能绑定此上下文中的程序集。通常应该避免这种情况。
那么为什么CLR首先会有加载器上下文？ Loader上下文有助于确保加载程序集时的加载顺序独立性。此外，它们还可以在程序集加载到不同的上下文时提供对程序集及其依赖项的隔离度量。
答案 0 :(得分：15)
可能只有少数人可以回答问题的“原因”部分。加载上下文主要与依赖关系的绑定有关。我的理解是：
Load，使用“传统”位置和绑定方法将程序集加载到AppDomain。加载的程序集可用作Load上下文中加载的后续程序集的依赖项。LoadFrom，将程序集加载到AppDomain查找依赖项（如Load），但有一点不同：这些程序集不会用于解析Load上下文程序集的依赖关系LoadNeither只加载一个程序集。如果它具有未解析的依赖项，则需要通过AssemblyResolve事件自行解决它们。这是一篇很棒的博客： http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx