.Net core 的热插拔机制的深入探索及卸载问题求救指南

这篇文章主要介绍了.Net core 的热插拔机制的深入探索及卸载问题求救指南,本文给大家啊介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下

一.依赖文件*.deps.json的读取.

依赖文件内容如下.一般位于编译生成目录中

 { "runtimeTarget": { "name": ".NETCoreApp,Version=v3.1", "signature": "" }, "compilationOptions": {}, "targets": { ".NETCoreApp,Version=v3.1": { "PluginSample/1.0.0": { "dependencies": { "Microsoft.Extensions.Hosting.Abstractions": "5.0.0-rc.2.20475.5" }, "runtime": { "PluginSample.dll": {} } }, "Microsoft.Extensions.Configuration.Abstractions/5.0.0-rc.2.20475.5": { "dependencies": { "Microsoft.Extensions.Primitives": "5.0.0-rc.2.20475.5" }, "runtime": { "lib/netstandard2.0/Microsoft.Extensions.Configuration.Abstractions.dll": { "assemblyVersion": "5.0.0.0", "fileVersion": "5.0.20.47505" } } ...

使用DependencyContextJsonReader加载依赖配置文件源码查看

 using (var dependencyFileStream = File.OpenRead("Sample.deps.json")) { using (DependencyContextJsonReader dependencyContextJsonReader = new DependencyContextJsonReader()) { //得到对应的实体文件 var dependencyContext = dependencyContextJsonReader.Read(dependencyFileStream); //定义的运行环境,没有,则为全平台运行. string currentRuntimeIdentifier= dependencyContext.Target.Runtime; //运行时所需要的dll文件 var assemblyNames= dependencyContext.RuntimeLibraries; } }

二.Net core多平台下RID(RuntimeIdentifier)的定义.

安装 Microsoft.NETCore.Platforms包,并找到runtime.json运行时定义文件.

 { "runtimes": { "win-arm64": { "#import": [ "win" ] }, "win-arm64-aot": { "#import": [ "win-aot", "win-arm64" ] }, "win-x64": { "#import": [ "win" ] }, "win-x64-aot": { "#import": [ "win-aot", "win-x64" ] }, }

NET Core RID依赖关系示意图

 win7-x64 win7-x86 | \ / | | win7 | | | | win-x64 | win-x86 \ | / win | any

.Net core常用发布平台RID如下

windows (win)

win-x64
win-x32
win-arm

macos (osx)

osx-x64

linux (linux)

linux-x64
linux-arm

1. .net core的runtime.json文件由微软提供:查看runtime.json.

2. runtime.json的runeims节点下,定义了所有的RID字典表以及RID树关系.

3. 根据*.deps.json依赖文件中的程序集定义RID标识,就可以判断出依赖文件中指向的dll是否能在某一平台运行.

4. 当程序发布为兼容模式时,我们出可以使用runtime.json文件选择性的加载平台dll并运行.

三.AssemblyLoadContext的加载原理

 public class PluginLoadContext : AssemblyLoadContext { private AssemblyDependencyResolver _resolver; public PluginLoadContext(string pluginFolder, params string[] commonAssemblyFolders) : base(isCollectible: true) { this.ResolvingUnmanagedDll += PluginLoadContext_ResolvingUnmanagedDll; this.Resolving += PluginLoadContext_Resolving; //第1步,解析des.json文件,并调用Load和LoadUnmanagedDll函数 _resolver = new AssemblyDependencyResolver(pluginFolder); //第6步,通过第4,5步,解析仍失败的dll会自动尝试调用主程序中的程序集, //如果失败,则直接抛出程序集无法加载的错误 } private Assembly PluginLoadContext_Resolving(AssemblyLoadContext assemblyLoadContext, AssemblyName assemblyName) { //第4步,Load函数加载程序集失败后,执行的事件 } private IntPtr PluginLoadContext_ResolvingUnmanagedDll(Assembly assembly, string unmanagedDllName) { //第5步,LoadUnmanagedDll加载native dll失败后执行的事件 } protected override Assembly Load(AssemblyName assemblyName) { //第2步,先执行程序集的加载函数 } protected override IntPtr LoadUnmanagedDll(string unmanagedDllName) { //第3步,先执行的native dll加载逻辑 } }

微软官方示例代码如下:示例具体内容

 class PluginLoadContext : AssemblyLoadContext { private AssemblyDependencyResolver _resolver; public PluginLoadContext(string pluginPath) { _resolver = new AssemblyDependencyResolver(pluginPath); } protected override Assembly Load(AssemblyName assemblyName) { string assemblyPath = _resolver.ResolveAssemblyToPath(assemblyName); if (assemblyPath != null) { //加载程序集 return LoadFromAssemblyPath(assemblyPath); } //返回null,则直接加载主项目程序集 return null; } protected override IntPtr LoadUnmanagedDll(string unmanagedDllName) { string libraryPath = _resolver.ResolveUnmanagedDllToPath(unmanagedDllName); if (libraryPath != null) { //加载native dll文件 return LoadUnmanagedDllFromPath(libraryPath); } //返回IntPtr.Zero,即null指针.将会加载主项中runtimes文件夹下的dll return IntPtr.Zero; } }

1. 官方这个示例是有问题的.LoadFromAssemblyPath()函数有bug,
该函数并不会加载依赖的程序集.正确用法是LoadFormStream()

2. Load和LoadUnmanagedDll函数实际上是给开发者手动加载程序集使用的,
自动加载应放到Resolving和ResolvingUnmanagedDll事件中
原因是,这样的加载顺序不会导致项目的程序集覆盖插件的程序集,造成程序集加载失败.

3. 手动加载时可以根据deps.json文件定义的runtime加载当前平台下的unmanaged dll文件.

这些平台相关的dll文件,一般位于发布目录中的runtimes文件夹中.