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

一.依赖文件*.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文件夹中.

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

如果主项目是.net core 3.1,插件项目不能选择.net core 2.0等,甚至不能选择.net standard库
否则会出现不可预知的问题.
插件是.net standard需要修改项目文件,<targetframeworks>netstandard;netcoreapp3.1</targetframeworks>
这样就可以发布为.net core项目.
若主项目中的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的简单形式,只是参数不同.官方说明
按照官方提供的默认参数测试,卸载仍然失败.说明这两种方式实现底层应该是不同的.