一.依賴文件*.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);
//定義的運行環(huán)境,沒有,則為全平臺運行.
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常用發(fā)布平臺RID如下
win-x64
win-x32
win-arm
osx-x64
linux-x64
linux-arm
1. .net core的runtime.json文件由微軟提供:查看runtime.json.
2. runtime.json的runeims節(jié)點下,定義了所有的RID字典表以及RID樹關系.
3. 根據(jù)*.deps.json依賴文件中的程序集定義RID標識,就可以判斷出依賴文件中指向的dll是否能在某一平臺運行.
4. 當程序發(fā)布為兼容模式時,我們出可以使用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函數(shù)
_resolver = new AssemblyDependencyResolver(pluginFolder);
//第6步,通過第4,5步,解析仍失敗的dll會自動嘗試調用主程序中的程序集,
//如果失敗,則直接拋出程序集無法加載的錯誤
}
private Assembly PluginLoadContext_Resolving(AssemblyLoadContext assemblyLoadContext, AssemblyName assemblyName)
{
//第4步,Load函數(shù)加載程序集失敗后,執(zhí)行的事件
}
private IntPtr PluginLoadContext_ResolvingUnmanagedDll(Assembly assembly, string unmanagedDllName)
{
//第5步,LoadUnmanagedDll加載native dll失敗后執(zhí)行的事件
}
protected override Assembly Load(AssemblyName assemblyName)
{
//第2步,先執(zhí)行程序集的加載函數(shù)
}
protected override IntPtr LoadUnmanagedDll(string unmanagedDllName)
{
//第3步,先執(zhí)行的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()函數(shù)有bug,
該函數(shù)并不會加載依賴的程序集.正確用法是LoadFormStream()
2. Load和LoadUnmanagedDll函數(shù)實際上是給開發(fā)者手動加載程序集使用的,
自動加載應放到Resolving和ResolvingUnmanagedDll事件中
原因是,這樣的加載順序不會導致項目的程序集覆蓋插件的程序集,造成程序集加載失敗.
3. 手動加載時可以根據(jù)deps.json文件定義的runtime加載當前平臺下的unmanaged dll文件.
這些平臺相關的dll文件,一般位于發(fā)布目錄中的runtimes文件夾中.
四.插件項目一定要和主項目使用同樣的運行時.
- 如果主項目是.net core 3.1,插件項目不能選擇.net core 2.0等,甚至不能選擇.net standard庫
- 否則會出現(xiàn)不可預知的問題.
- 插件是.net standard需要修改項目文件,TargetFrameworks>netstandard;netcoreapp3.1/TargetFrameworks>
- 這樣就可以發(fā)布為.net core項目.
- 若主項目中的nuget包不適合當前平臺,則會報Not Support Platform的異常.這時如果主項目是在windows上, 就需要把項目發(fā)布目標設置為win-x64.這屬于nuget包依賴關系存在錯誤描述.
五.AssemblyLoadContext.UnLoad()并不會拋出任何異常.
當你調用AssemblyLoadContext.UnLoad()卸載完插件以為相關程序集已經(jīng)釋放,那你可能就錯了.官方文檔表明卸載執(zhí)行失敗會拋出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等不能直接定義在任何類中.
否則在插件卸載時會失敗.當時為了測試是否卸載成功,采用手動加載,執(zhí)行,卸載了1000次,
發(fā)現(xiàn)內存一直上漲,則表示卸載失敗.
2. 參照官方文檔后了解了WeakReferece類.使用該類與AssemblyLoadContext關聯(lián),當手動GC清理時,
AssemblyLoadContext就會變?yōu)閚ull值,如果沒有變?yōu)閚ull值則表示卸載失敗.
3. 使用WeakReference關聯(lián)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就會變?yōu)镕alse,即AssemblyLoadContext卸載失敗.
for (int i = 0; weakReference.IsAlive (i 10); i++)
{
GC.Collect();
GC.WaitForPendingFinalizers();
}
}
4. 為了解決以上問題.可以把需要的變量放到靜態(tài)字典中.在Unload之前把對應的Key值刪除掉,即可.
七.程序集的異步函數(shù)執(zhí)行為何會阻止插件程序的卸載?
public class SimpleService
{
//同步執(zhí)行,插件卸載成功
public void Run(string name)
{
Console.WriteLine($"Hello {name}!");
}
//異步執(zhí)行,卸載成功
public Task RunAsync(string name)
{
Console.WriteLine($"Hello {name}!");
return Task.CompletedTask;
}
//異步執(zhí)行,卸載成功
public Task RunTask(string name)
{
return Task.Run(() => {
Console.WriteLine($"Hello {name}!");
});
}
//異步執(zhí)行,卸載成功
public Task RunWaitTask(string name)
{
return Task.Run( async ()=> {
while (true)
{
if (CancellationTokenSource.IsCancellationRequested)
{
break;
}
await Task.Delay(1000);
Console.WriteLine($"Hello {name}!");
}
});
}
//異步執(zhí)行,卸載成功
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}!");
}
});
}
//異步執(zhí)行,卸載失敗
public async Task RunWait(string name)
{
while (true)
{
if (CancellationTokenSource.IsCancellationRequested)
{
break;
}
await Task.Delay(1000);
Console.WriteLine($"Hello {name}!");
}
}
//異步執(zhí)行,卸載失敗
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. 以上測試可以看出,如果插件調用的是一個常規(guī)帶wait的async異步函數(shù),則插件一定會卸載失敗.
原因推測是返回的結果是編譯器自動生成的狀態(tài)機實現(xiàn)的,而狀態(tài)機是在插件中定義的.
2. 如果在插件中使用Task.Factory.StartNew函數(shù)也會調用失敗,原因不明.
官方文檔說和Task.Run函數(shù)是Task.Factory.StartNew的簡單形式,只是參數(shù)不同.官方說明
按照官方提供的默認參數(shù)測試,卸載仍然失敗.說明這兩種方式實現(xiàn)底層應該是不同的.
八.正確卸載插件的方式
- 任何與插件相關的非局部變量,不能定義在類中,如果想全局調用只能放到Dictionary中,
- 在調用插件卸載之前,刪除相關鍵值.
- 任何通過插件返回的變量,不能為插件內定義的變量類型.盡量使用json傳遞參數(shù).
- 插件入口函數(shù)盡量使用同步函數(shù),如果為異步函數(shù),只能使用Task.Run方式裹所有邏輯.
- 如果有任何疑問或不同意見,請賜教.
NFinal2開源框架。https://git.oschina.net/LucasDot/NFinal2/tree/master
到此這篇關于.Net core 的熱插拔機制的深入探索及卸載問題求救指南的文章就介紹到這了,更多相關.Net core熱插拔機制內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
您可能感興趣的文章:- .Net Core2.1 WebAPI新增Swagger插件詳解
