在.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解决这个问题。