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

2022-11-13 11:11:58 程序 加载 失败

.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中从资源文件中获取程序集返回。

客户端更新:

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

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。

相关文章