.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文件夹中.

四.插件项目一定要和主项目使用同样的运行时.

  1. 如果主项目是.net core 3.1,插件项目不能选择.net core 2.0等,甚至不能选择.net standard库

    否则会出现不可预知的问题.
  2. 插件是.net standard需要修改项目文件,<TargetFrameworks>netstandard;netcoreapp3.1</TargetFrameworks>
  3. 这样就可以发布为.net core项目.
  4. 若主项目中的nuget包不适合当前平台,则会报Not Support Platform的异常.这时如果主项目是在windows上, 就需要把项目发布目标设置为win-x64.这属于nuget包依赖关系存在错误描述.

五.AssemblyLoadContext.UnLoad()并不会抛出任何异常.

当你调用AssemblyLoadContext.UnLoad()卸载完插件以为相关程序集已经释放,那你可能就错了.
官方文档表明卸载执行失败会抛出InvalidOperationException,不允许卸载官方说明

但实际测试中,卸载失败,但并未报错.


六.反射程序集相关变量的定义为何阻止插件程序集卸载?

插件

namespace PluginSample
{
public class SimpleService
{
public void Run(string name)
{
Console.WriteLine($"Hello World!");
}
}
}

加载插件

namespace Test
{
public class PluginLoader
{
pubilc AssemblyLoadContext assemblyLoadContext;
public Assembly assembly;
public Type type;
public MethodInfo method;
public void Load()
{
assemblyLoadContext = new PluginLoadContext("插件文件夹");
assembly = alc.Load(new AssemblyName("PluginSample"));
type = assembly.GetType("PluginSample.SimpleService");
method=type.GetMethod()
}
}
}

1. 在主项目程序中.AssemblyLoadContext,Assembly,Type,MethodInfo等不能直接定义在任何类中.

否则在插件卸载时会失败.当时为了测试是否卸载成功,采用手动加载,执行,卸载了1000次,

发现内存一直上涨,则表示卸载失败.

2. 参照官方文档后了解了WeakReferece类.使用该类与AssemblyLoadContext关联,当手动GC清理时,

AssemblyLoadContext就会变为null值,如果没有变为null值则表示卸载失败.

3. 使用WeakReference关联AssemblyLoadContext并判断是否卸载成功

public void Load(out WeakReference weakReference)
{
var assemblyLoadContext = new PluginLoadContext("插件文件夹");
weakReference = new WeakReference(pluginLoadContext, true);
assemblyLoadContext.UnLoad();
}
public void Check()
{
WeakReference weakReference=null;
Load(out weakReference);
//一般第二次,IsAlive就会变为False,即AssemblyLoadContext卸载失败.
for (int i = 0; weakReference.IsAlive && (i < 10); i++)
{
GC.Collect();
GC.WaitForPendingFinalizers();
}
}

4. 为了解决以上问题.可以把需要的变量放到静态字典中.在Unload之前把对应的Key值删除掉,即可.

七.程序集的异步函数执行为何会阻止插件程序的卸载?

public class SimpleService
{
//同步执行,插件卸载成功
public void Run(string name)
{
Console.WriteLine($"Hello {name}!");
}
//异步执行,卸载成功
public Task RunAsync(string name)
{
Console.WriteLine($"Hello {name}!");
return Task.CompletedTask;
}
//异步执行,卸载成功
public Task RunTask(string name)
{
return Task.Run(() => {
Console.WriteLine($"Hello {name}!");
});
}
//异步执行,卸载成功
public Task RunWaitTask(string name)
{
return Task.Run( async ()=> {
while (true)
{
if (CancellationTokenSource.IsCancellationRequested)
{
break;
}
await Task.Delay(1000);
Console.WriteLine($"Hello {name}!");
}
});
}
//异步执行,卸载成功
public Task RunWaitTaskForCancel(string name, CancellationToken cancellation)
{
return Task.Run(async () => {
while (true)
{
if (cancellation.IsCancellationRequested)
{
break;
}
await Task.Delay(1000);
Console.WriteLine($"Hello {name}!");
}
});
}
//异步执行,卸载失败
public async Task RunWait(string name)
{
while (true)
{
if (CancellationTokenSource.IsCancellationRequested)
{
break;
}
await Task.Delay(1000);
Console.WriteLine($"Hello {name}!");
} }
//异步执行,卸载失败
public Task RunWaitNewTask(string name)
{
return Task.Factory.StartNew(async ()=> {
while (true)
{
if (CancellationTokenSource.IsCancellationRequested)
{
break;
}
await Task.Delay(1000);
Console.WriteLine($"Hello {name}!");
}
},TaskCreationOptions.DenyChildAttach);
}
}

1. 以上测试可以看出,如果插件调用的是一个常规带wait的async异步函数,则插件一定会卸载失败.

原因推测是返回的结果是编译器自动生成的状态机实现的,而状态机是在插件中定义的.

2. 如果在插件中使用Task.Factory.StartNew函数也会调用失败,原因不明.

官方文档说和Task.Run函数是Task.Factory.StartNew的简单形式,只是参数不同.官方说明

按照官方提供的默认参数测试,卸载仍然失败.说明这两种方式实现底层应该是不同的.

八.正确卸载插件的方式

  1. 任何与插件相关的非局部变量,不能定义在类中,如果想全局调用只能放到Dictionary中,

    在调用插件卸载之前,删除相关键值.
  2. 任何通过插件返回的变量,不能为插件内定义的变量类型.尽量使用json传递参数.
  3. 插件入口函数尽量使用同步函数,如果为异步函数,只能使用Task.Run方式裹所有逻辑.
  4. 如果有任何疑问或不同意见,请赐教.

.Net core 的热插拔机制的深入探索,以及卸载问题求救指南.的更多相关文章

  1. InnoDB的锁机制浅析(二)—探索InnoDB中的锁(Record锁/Gap锁/Next-key锁/插入意向锁)

    Record锁/Gap锁/Next-key锁/插入意向锁 文章总共分为五个部分: InnoDB的锁机制浅析(一)-基本概念/兼容矩阵 InnoDB的锁机制浅析(二)-探索InnoDB中的锁(Recor ...

  2. 集群环境下,你不得不注意的ASP.NET Core Data Protection 机制

    引言 最近线上环境遇到一个问题,就是ASP.NET Core Web应用在单个容器使用正常,扩展多个容器无法访问的问题.查看容器日志,发现以下异常: System.Security.Cryptogra ...

  3. .Net Core 项目中的包引用探索(使用VSCode)

    本文组织有点乱,先说结论吧: 1 在 project.json 文件中声明包引用. 而不是像以前那样可以直接引用 dll. 2 使用 dotnet restore 命令后,nuget 会把声明的依赖项 ...

  4. 深入研究.NET Core的本地化机制

    ASP.NET Core中提供了一些本地化服务和中间件,可将网站本地化为不同的语言文化. ASP.NET Core中我们可以使用Microsoft.AspNetCore.Localization库来实 ...

  5. C#无限极分类树-创建-排序-读取 用Asp.Net Core+EF实现之方法二:加入缓存机制

    在上一篇文章中我用递归方法实现了管理菜单,在上一节我也提到要考虑用缓存,也算是学习一下.Net Core的缓存机制. 关于.Net Core的缓存,官方有三种实现: 1.In Memory Cachi ...

  6. PHP服务器脚本 PHP内核探索:新垃圾回收机制说明

    在5.2及更早版本的PHP中,没有专门的垃圾回收器GC(Garbage Collection),引擎在判断一个变量空间是否能够被释放的时候是依据这个变量的zval的refcount的值,如果refco ...

  7. ASP.NET Core 的启动和运行机制

    目录 ASP .NET Core 的运行机制 ASP .NET Core 的启动 ASP .NET Core 的管道和中间件 参考 ASP .NET Core 的运行机制 Web Server: AS ...

  8. ASP.NET Core 认证与授权[6]:授权策略是怎么执行的?

    在上一章中,详细介绍了 ASP.NET Core 中的授权策略,在需要授权时,只需要在对应的Controler或者Action上面打上[Authorize]特性,并指定要执行的策略名称即可,但是,授权 ...

  9. 如何在ASP.NET Core程序启动时运行异步任务(1)

    原文:Running async tasks on app startup in ASP.NET Core (Part 1) 作者:Andrew Lock 译者:Lamond Lu 背景 当我们做项目 ...

随机推荐

  1. Spring Boot 配置中的敏感信息如何保护?

    在之前的系列教程中,我们已经介绍了非常多关于Spring Boot配置文件中的各种细节用法,比如:参数间的引用.随机数的应用.命令行参数的使用.多环境的配置管理等等. 这些配置相关的知识都是Sprin ...

  2. 北航OO第四单元——UML图解析

    北航OO第四单元--UML图解析 作业要求简析 刚接触本次作业可能需要花上一会才能搞清楚到底是要我们写个啥,在这里简单说一下: UML图的保存格式.mdj文件是以json文件的形式存储的,将每一个Um ...

  3. Easylogging++的使用及扩展

    目录 简介 使用 扩展 配置日志路径 时间滚动日志 自动删除日志 封装到一个头文件 源代码优化(不推荐) 附件 简介 Easylogging++ 是用于 C++ 应用程序的单头高效日志库.它非常强大, ...

  4. IDEA spring boot项目插件打包方式jar

    一.打包 1.pom.xml中添加插件依赖 <build> <plugins> <plugin> <!--打包成可执行jar--> <groupI ...

  5. 程序员作图工具和技巧,你 get 了么?

    分享程序员常用的画图软件和小技巧 大家好,我是鱼皮. 说实话,我觉得做个程序员挺好的.日常工作有很多,写代码.对需求.写方案等等,但我最爱画图:流程图.架构图.交互图.功能模块图.UML 类图.部署图 ...

  6. 当Atlas遇见Flink——Apache Atlas 2.2.0发布!

    距离上次atlas发布新版本已经有一年的时间了,但是这一年元数据管理平台的发展一直没有停止.Datahub,Amundsen等等,都在不断的更新着自己的版本.但是似乎Atlas在元数据管理,数据血缘领 ...

  7. 【转】新说Mysql事务隔离级别

    作者:孤独烟 转自:https://www.cnblogs.com/rjzheng/p/9955395.html 引言 大家在面试中一定碰到过 说说事务的隔离级别吧? 老实说,事务隔离级别这个问题,无 ...

  8. Servlet的特点及运行过程

  9. Go版本管理--go.sum

    目录 1. 简介 2. go.sum文件记录 3. 生成 4.校验 5.校验和数据库 1. 简介 为了确保一致性构建,Go引入了go.mod文件来标记每个依赖包的版本,在构建过程中go命令会下载go. ...

  10. Nginx location 和 proxy_pass路径配置详解

    目录 一.Nginx location 基本配置 1.1.Nginx 配置文件 1.2 .Python 脚本 二.测试 2.1.测试 location 末尾存在 / 和 proxy_pass末尾存在 ...