.net加载失败的程序集重新加载

在.net程序中，程序集是Lazy加载的，只有在用的时候才会去加载，当程序集加载失败时，会触发AppDomain.AssemblyResolve的事件，在这个事件中，我们甚至还可以进行补救，从别得地方重新加载程序集。

AppDomain . CurrentDomain . AssemblyResolve   +=  (s, e) =>
{
     byte [] content =  getLibBytes (e. Name );
     return   Assembly . Load (content);
};

这个功能如果使用起来就非常灵活了，它可以控制我们自由控制程序集的加载方式。常用的方法有如下几个：

程序集保护：

.net程序是非常容易反编译的，这个特性提供了混淆外的另一个方式。由于动态调用的方式下，程序集不需要是原始dll，甚至都不需要存储在磁盘上。可以通过直接不让使用者获取到程序集的dll的方式防止反编译。

发布的程序的时候，不直接发布需要保护的程序集，将程序集加密后发布，或者直接加密后存储在服务器上。使用的时候，在AssemblyResolve中获取加密后的程序集，解密后返回。

程序集合并：

WPF程序由于使用了反射，使用传统的ILMerge的方式合并后，由于程序集变化了，往往不能正常工作。

有很多工具，通过将程序集合并到exe的资源文件中，使用的时候，再在ssemblyResolve中从资源文件中获取程序集返回。具体可以参看我之前的文章： 使用LibZ合并.Net程序集

客户端更新：

CS模式的程序一个不足就是更新不方便，可以将程序集存储在文件数据库中，直接更新程序集数据库就可以很方便的实现程序集更新。

程序集存储分离：

使用微服务模式时，很多部署在同一个服务器上的服务共用着相同的程序集（第三方的Nuget库），这些程序集更新频率很低，并且混在一起存储使得我们不容易找到业务程序集。

可以将这些程序集集中存储在独立的位置。服务文件夹中只发布我们的业务程序集，看起来更加清晰，更新也更加方便。

.net core

在.net core中，这个机制也是可以使用的，不过接口发生了一点变化：

AssemblyLoadContext . Default . Resolving   +=  (context, assembly) =>
{
     var  content =  getLibBytes (assembly. FullName );
     return   Assembly . Load (content);
};

需要说明的是，如果是使用 dotnet xxx.dll 的方式运行的话，dotnet 程序会首先通过 xxx.deps.json文件来获取所有相关的依赖性，从而还没有进入程序就报错。

可以通过修改 xxx.deps.json去掉依赖项，或者干脆直接删掉xxx.deps.json解决这个问题。