.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方式裹所有邏輯.
- 如果有任何疑問或不同意見,請賜教.
NFinal2開源框架。https://git.oschina.net/LucasDot/NFinal2/tree/master
到此這篇關於.Net core 的熱插拔機制的深入探索及解除安裝問題求救指南的文章就介紹到這了,更多相關.Net core熱插拔機制內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！