.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檔案夾中.
四.插件專案一定要和主專案使用同樣的運行時.
- 如果主專案是.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的簡單形式,只是引數不同.官方說明
按照官方提供的默認引數測驗,卸載仍然失敗.說明這兩種方式實作底層應該是不同的.
八.正確卸載插件的方式
- 任何與插件相關的非區域變數,不能定義在類中,如果想全域呼叫只能放到Dictionary中,
在呼叫插件卸載之前,洗掉相關鍵值. - 任何通過插件回傳的變數,不能為插件內定義的變數型別.盡量使用json傳遞引數.
- 插件入口函式盡量使用同步函式,如果為異步函式,只能使用Task.Run方式裹所有邏輯.
- 如果有任何疑問或不同意見,請賜教.
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/209819.html
標籤：.NET技术
下一篇：DotnetCore 單檔案發布