linux热插拔原理,.NET Core 的热插拔机制的深入探索

原标题：.NET Core 的热插拔机制的深入探索

转自：老禄

cnblogs.com/LucasDot/p/13956384.html

一、依赖文件*.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(DependencyContextJsonReader dependencyContextJsonReader = newDependencyContextJsonReader)

{

//得到对应的实体文件

vardependencyContext = dependencyContextJsonReader.Read(dependencyFileStream);

//定义的运行环境,没有,则为全平台运行.

stringcurrentRuntimeIdentifier= dependencyContext.Target.Runtime;

//运行时所需要的dll文件

varassemblyNames= 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如下

1、windows (win)

win-x64

win-x32

win-arm

2、macos (osx)

osx-x64

3、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的加载原理

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会自动尝试调用主程序中的程序集,

//如果失败,则直接抛出程序集无法加载的错误

}

privateAssembly PluginLoadContext_Resolving( AssemblyLoadContext assemblyLoadContext, AssemblyName assemblyName)

{

//第4步,Load函数加载程序集失败后,执行的事件

}

privateIntPtr PluginLoadContext_ResolvingUnmanagedDll( Assembly assembly, stringunmanagedDllName)

{

//第5步,LoadUnmanagedDll加载native dll失败后执行的事件

}

protectedoverrideAssembly Load( AssemblyName assemblyName)

{

//第2步,先执行程序集的加载函数

}

protectedoverrideIntPtr LoadUnmanagedDll( stringunmanagedDllName)

{

//第3步,先执行的native dll加载逻辑

}

}

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

classPluginLoadContext: AssemblyLoadContext

{

privateAssemblyDependencyResolver _resolver;

publicPluginLoadContext( stringpluginPath)

{

_resolver = newAssemblyDependencyResolver(pluginPath);

}

protectedoverrideAssembly Load( AssemblyName assemblyName)

{

stringassemblyPath = _resolver.ResolveAssemblyToPath(assemblyName);

if(assemblyPath != null)

{

//加载程序集

returnLoadFromAssemblyPath(assemblyPath);

}

//返回null,则直接加载主项目程序集

returnnull;

}

protectedoverrideIntPtr LoadUnmanagedDll( stringunmanagedDllName)

{

stringlibraryPath = _resolver.ResolveUnmanagedDllToPath(unmanagedDllName);

if(libraryPath != null)

{

//加载native dll文件

returnLoadUnmanagedDllFromPath(libraryPath);

}

//返回IntPtr.Zero,即null指针.将会加载主项中runtimes文件夹下的dll

returnIntPtr.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需要修改项目文件,netstandard;netcoreapp3.1

3、这样就可以发布为.net core项目.

4、若主项目中的nuget包不适合当前平台,则会报Not Support Platform的异常.这时如果主项目是在windows上, 就需要把项目发布目标设置为win-x64.这属于nuget包依赖关系存在错误描述.

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

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

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

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

插件

namespacePluginSample

{

publicclassSimpleService

{

publicvoidRun( stringname)

{

Console.WriteLine( $"Hello World!");

}

}

}

加载插件

namespaceTest

{

publicclassPluginLoader

{

pubilc AssemblyLoadContext assemblyLoadContext;

publicAssembly assembly;

publicType type;

publicMethodInfo method;

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( outWeakReference weakReference)

{

varassemblyLoadContext = newPluginLoadContext( "插件文件夹");

weakReference = newWeakReference(pluginLoadContext, true);

assemblyLoadContext.UnLoad;

}

publicvoidCheck

{

WeakReference weakReference= 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}!");

}

//异步执行,卸载成功

publicTask RunAsync( stringname)

{

Console.WriteLine( $"Hello {name}!");

returnTask.CompletedTask;

}

//异步执行,卸载成功

publicTask RunTask( stringname)

{

returnTask.Run( => {

Console.WriteLine( $"Hello {name}!");

});

}

//异步执行,卸载成功

publicTask RunWaitTask( stringname)

{

returnTask.Run( async=> {

while( true)

{

if(CancellationTokenSource.IsCancellationRequested)

{

break;

}

awaitTask.Delay( 1000);

Console.WriteLine( $"Hello {name}!");

}

});

}

//异步执行,卸载成功

publicTask RunWaitTaskForCancel( stringname, CancellationToken cancellation)

{

returnTask.Run( async=> {

while( true)

{

if(cancellation.IsCancellationRequested)

{

break;

}

awaitTask.Delay( 1000);

Console.WriteLine( $"Hello {name}!");

}

});

}

//异步执行,卸载失败

publicasyncTask RunWait( stringname)

{

while( true)

{

if(CancellationTokenSource.IsCancellationRequested)

{

break;

}

awaitTask.Delay( 1000);

Console.WriteLine( $"Hello {name}!");

}

}

//异步执行,卸载失败

publicTask RunWaitNewTask( 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的简单形式,只是参数不同.官方说明

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

八、正确卸载插件的方式

1、任何与插件相关的非局部变量,不能定义在类中,如果想全局调用只能放到Dictionary中,在调用插件卸载之前,删除相关键值.

2、任何通过插件返回的变量,不能为插件内定义的变量类型.尽量使用json传递参数.

3、插件入口函数尽量使用同步函数,如果为异步函数,只能使用Task.Run方式裹所有逻辑.

4、如果有任何疑问或不同意见,请赐教.

NFinal2开源框架：https://git.oschina.net/LucasDot/NFinal2/tree/master返回搜狐，查看更多

责任编辑：