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

2023-07-12 10:53:04 273

一.依赖文件*.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(vardependencyFileStream=File.OpenRead("Sample.deps.json"))
{
using(DependencyContextJsonReaderdependencyContextJsonReader=newDependencyContextJsonReader())
{
//得到对应的实体文件
vardependencyContext=
dependencyContextJsonReader.Read(dependencyFileStream);
//定义的运行环境,没有,则为全平台运行.
stringcurrentRuntimeIdentifier=dependencyContext.Target.Runtime;
//运行时所需要的dll文件
varassemblyNames=dependencyContext.RuntimeLibraries;
}
}

二.Netcore多平台下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"
]
},
}

NETCoreRID依赖关系示意图

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

.Netcore常用发布平台RID如下

windows(win)

win-x64
win-x32
win-arm

macos(osx)

osx-x64

linux(linux)

linux-x64
linux-arm

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

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

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

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

三.AssemblyLoadContext的加载原理

publicclassPluginLoadContext:AssemblyLoadContext
{
privateAssemblyDependencyResolver_resolver;
publicPluginLoadContext(stringpluginFolder,paramsstring[]commonAssemblyFolders):base(isCollectible:true)
{
this.ResolvingUnmanagedDll+=PluginLoadContext_ResolvingUnmanagedDll;
this.Resolving+=PluginLoadContext_Resolving;
//第1步,解析des.json文件,并调用Load和LoadUnmanagedDll函数
_resolver=newAssemblyDependencyResolver(pluginFolder);
//第6步,通过第4,5步,解析仍失败的dll会自动尝试调用主程序中的程序集,
//如果失败,则直接抛出程序集无法加载的错误
}
privateAssemblyPluginLoadContext_Resolving(AssemblyLoadContextassemblyLoadContext,AssemblyNameassemblyName)
{
//第4步,Load函数加载程序集失败后,执行的事件
}
privateIntPtrPluginLoadContext_ResolvingUnmanagedDll(Assemblyassembly,stringunmanagedDllName)
{
//第5步,LoadUnmanagedDll加载nativedll失败后执行的事件
}
protectedoverrideAssemblyLoad(AssemblyNameassemblyName)
{
//第2步,先执行程序集的加载函数
}
protectedoverrideIntPtrLoadUnmanagedDll(stringunmanagedDllName)
{
//第3步,先执行的nativedll加载逻辑
}
}

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

classPluginLoadContext:AssemblyLoadContext
{
privateAssemblyDependencyResolver_resolver;

publicPluginLoadContext(stringpluginPath)
{
_resolver=newAssemblyDependencyResolver(pluginPath);
}

protectedoverrideAssemblyLoad(AssemblyNameassemblyName)
{
stringassemblyPath=_resolver.ResolveAssemblyToPath(assemblyName);
if(assemblyPath!=null)
{
//加载程序集
returnLoadFromAssemblyPath(assemblyPath);
}
//返回null,则直接加载主项目程序集
returnnull;
}

protectedoverrideIntPtrLoadUnmanagedDll(stringunmanagedDllName)
{
stringlibraryPath=_resolver.ResolveUnmanagedDllToPath(unmanagedDllName);
if(libraryPath!=null)
{
//加载nativedll文件
returnLoadUnmanagedDllFromPath(libraryPath);
}
//返回IntPtr.Zero,即null指针.将会加载主项中runtimes文件夹下的dll
returnIntPtr.Zero;
}
}

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

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

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

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

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

如果主项目是.netcore3.1,插件项目不能选择.netcore2.0等,甚至不能选择.netstandard库
否则会出现不可预知的问题.
插件是.netstandard需要修改项目文件,netstandard;netcoreapp3.1
这样就可以发布为.netcore项目.
若主项目中的nuget包不适合当前平台,则会报NotSupportPlatform的异常.这时如果主项目是在windows上,就需要把项目发布目标设置为win-x64.这属于nuget包依赖关系存在错误描述.

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

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

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

插件

namespacePluginSample
{
publicclassSimpleService
{
publicvoidRun(stringname)
{
Console.WriteLine($"HelloWorld!");
}
}
}

加载插件

namespaceTest
{
publicclassPluginLoader
{
pubilcAssemblyLoadContextassemblyLoadContext;
publicAssemblyassembly;
publicTypetype;
publicMethodInfomethod;
publicvoidLoad()
{
assemblyLoadContext=newPluginLoadContext("插件文件夹");
assembly=alc.Load(newAssemblyName("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并判断是否卸载成功

publicvoidLoad(outWeakReferenceweakReference)
{
varassemblyLoadContext=newPluginLoadContext("插件文件夹");
weakReference=newWeakReference(pluginLoadContext,true);
assemblyLoadContext.UnLoad();
}
publicvoidCheck()
{
WeakReferenceweakReference=null;
Load(outweakReference);
//一般第二次,IsAlive就会变为False,即AssemblyLoadContext卸载失败.
for(inti=0;weakReference.IsAlive&&(i<10);i++)
{
GC.Collect();
GC.WaitForPendingFinalizers();
}
}

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

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

publicclassSimpleService
{
//同步执行,插件卸载成功
publicvoidRun(stringname)
{
Console.WriteLine($"Hello{name}!");
}
//异步执行,卸载成功
publicTaskRunAsync(stringname)
{
Console.WriteLine($"Hello{name}!");
returnTask.CompletedTask;
}
//异步执行,卸载成功
publicTaskRunTask(stringname)
{
returnTask.Run(()=>{
Console.WriteLine($"Hello{name}!");
});
}
//异步执行,卸载成功
publicTaskRunWaitTask(stringname)
{
returnTask.Run(async()=>{
while(true)
{
if(CancellationTokenSource.IsCancellationRequested)
{
break;
}
awaitTask.Delay(1000);
Console.WriteLine($"Hello{name}!");
}
});
}
//异步执行,卸载成功
publicTaskRunWaitTaskForCancel(stringname,CancellationTokencancellation)
{
returnTask.Run(async()=>{
while(true)
{
if(cancellation.IsCancellationRequested)
{
break;
}
awaitTask.Delay(1000);
Console.WriteLine($"Hello{name}!");
}
});
}
//异步执行,卸载失败
publicasyncTaskRunWait(stringname)
{
while(true)
{
if(CancellationTokenSource.IsCancellationRequested)
{
break;
}
awaitTask.Delay(1000);
Console.WriteLine($"Hello{name}!");
}

}
//异步执行,卸载失败
publicTaskRunWaitNewTask(stringname)
{
returnTask.Factory.StartNew(async()=>{
while(true)
{
if(CancellationTokenSource.IsCancellationRequested)
{
break;
}
awaitTask.Delay(1000);
Console.WriteLine($"Hello{name}!");
}
},TaskCreationOptions.DenyChildAttach);
}
}

1.以上测试可以看出,如果插件调用的是一个常规带wait的async异步函数,则插件一定会卸载失败.
原因推测是返回的结果是编译器自动生成的状态机实现的,而状态机是在插件中定义的.

2.如果在插件中使用Task.Factory.StartNew函数也会调用失败,原因不明.
官方文档说和Task.Run函数是Task.Factory.StartNew的简单形式,只是参数不同.官方说明
按照官方提供的默认参数测试,卸载仍然失败.说明这两种方式实现底层应该是不同的.

八.正确卸载插件的方式

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

NFinal2开源框架。https://git.oschina.net/LucasDot/NFinal2/tree/master

到此这篇关于.Netcore的热插拔机制的深入探索及卸载问题求救指南的文章就介绍到这了,更多相关.Netcore热插拔机制内容请搜索毛票票以前的文章或继续浏览下面的相关文章希望大家以后多多支持毛票票！