首先，查看所需的Assembly是否已经加载过，如果已经加载了，那就直接使用那个已经加载的Assembly的版本与当前所需的版本进行比对，如果匹配，则使用那个已经加载的Assembly，如果不匹配，则抛出FileLoadException，执行结束
然后，看Assembly是否已被强签名（Strongly Named），如果是，则去GAC里查找Assembly。如果找到，则直接加载，整个Assembly加载过程结束。如果没有找到，那么就进行下一步，继续搜索Assembly文件。当然，如果Assembly没有进行强签名，那么就跳过这一步，直接继续
接着，CLR开始搜索（Probing）可能的Assembly位置，这又要分多种情况：
首先，查看文件中是否有指定<codeBase>，codeBase配置允许应用程序针对Assembly的不同版本指定装载地址，遵循如下规律：
如果所指定的Assembly文件位于当前应用程序域的启动目录（或其子目录）下，则使用相对路径指定href的值
如果所指定的Assembly文件位于其它目录，或任何其它地方，则href必须给出全路径，并且Assembly必须强签名的
然后，CLR对应用程序域的根目录以及相关的子目录进行探索：
假设Assembly的名字是abc.dll，那么CLR会探索以下目录：
[appdomain_base]\abc.dll
[appdomain_base]\abc\abc.dll
假设abc.dll还有语言设置（culture不是neutral），那么CLR会探索以下目录：
[appdomain_base]\[culture]\abc.dll
[appdomain_base]\[culture]\abc\abc.dll
如果找到符合版本的Assembly，则加载，否则进入下一步
最后，CLR会查看应用程序配置文件中是否有<probling>节点，如果有，则按probling节点所指定的privatePath值进行逐一探索。这个过程也会考虑culture的因素，类似于上面这步这样，对相应的子目录进行搜索。如果找到对应的Assembly，则加载，否则抛出FileLoadException，整个加载过程结束。注意，这里“逐一探索”的过程，不是遍历并找最佳匹配的过程。CLR仅根据Assembly的名字（不带版本号的名字）在privatePath下查找Assembly的文件，找到第一个名字匹配但是版本不匹配的话，就抛异常并终止加载了，它不会继续搜索privatePath中余下的其它路径
在加载Assembly文件失败的时候，AppDomain会触发AssemblyResolve的事件，在这个事件的订阅函数中，允许客户程序自定义对加载失败的Assembly的处理方式，比如，可以通过Assembly.LoadFrom或者Assembly.LoadFile调用“手动地”将Assembly加载到AppDomain。
fuslogvw Assembly绑定日志查看器在.NET SDK中带了一个fuslogvw.exe的应用程序，通过它可以查看详细的Assembly加载过程。使用方法非常简单，使用管理员身份启动Visual Studio 2017 Developer Command Prompt，然后在命令行输入fuslogvw.exe，即可启动日志查看器。启动之后，点击Settings按钮，以启用日志记录功能：
日志启动之后，点击Refresh按钮，然后启动你的.NET应用程序，就可以看到当前应用程序所依赖的Assembly的加载过程日志了：
接下来，我会做一个例子程序，然后使用这个工具来分析Assembly的加载过程。
插件系统的实现与Assembly加载过程的分析理论结合实际，看看如何通过实际代码来诠释以上所述Assembly的加载过程。一个比较好的例子就是设计一个简单的插件系统，并通过观察系统加载插件的过程，来了解Assembly加载的来龙去脉。为了简单直观，我把这个插件系统称为PluginDemo。这个插件很简单，主体程序是一个控制台应用程序，然后我们实现两个插件：Earth和Mars，在不同的插件的Initialize方法中，会输出不同的字符串。
整个应用程序的项目结构如下：
该插件系统包含4个C#的项目：
PluginDemo.Common：它定义了AddIn抽象类，所有的插件实现都需要继承于这个抽象类。此外，AddInDefinition类是一个用来保存插件Metadata的类。为了演示，插件的Metadata仅仅包含插件类型的Assembly Qualified Name