.Net core 的熱插拔機制的深刻探索,以及卸載問題求救指南.

.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

    • linux-x64
    • linux-armgit

1. .net core的runtime.json文件由微軟提供:查看runtime.json.github

2. runtime.json的runeims節點下,定義了全部的RID字典表以及RID樹關係.macos

3. 根據*.deps.json依賴文件中的程序集定義RID標識,就能夠判斷出依賴文件中指向的dll是否能在某一平臺運行.json

4. 當程序發佈爲兼容模式時,咱們出能夠使用runtime.json文件選擇性的加載平臺dll並運行.windows


三.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() api

2. Load和LoadUnmanagedDll函數其實是給開發者手動加載程序集使用的,
自動加載應放到Resolving和ResolvingUnmanagedDll事件中
緣由是,這樣的加載順序不會致使項目的程序集覆蓋插件的程序集,形成程序集加載失敗. app

3. 手動加載時能夠根據deps.json文件定義的runtime加載當前平臺下的unmanaged dll文件.  異步

這些平臺相關的dll文件,通常位於發佈目錄中的runtimes文件夾中.async

四.插件項目必定要和主項目使用一樣的運行時.  

  1. 若是主項目是.net core 3.1,插件項目不能選擇.net core 2.0等,甚至不能選擇.net standard庫
    不然會出現不可預知的問題.
  2. 插件是.net standard須要修改項目文件,<TargetFrameworks>netstandard;netcoreapp3.1</TargetFrameworks>
  3. 這樣就能夠發佈爲.net core項目.
  4. 若主項目中的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的簡單形式,只是參數不一樣.官方說明
按照官方提供的默認參數測試,卸載仍然失敗.說明這兩種方式實現底層應該是不一樣的.

八.正確卸載插件的方式

  1. 任何與插件相關的非局部變量,不能定義在類中,若是想全局調用只能放到Dictionary中,
    在調用插件卸載以前,刪除相關鍵值.
  2. 任何經過插件返回的變量,不能爲插件內定義的變量類型.儘可能使用json傳遞參數.
  3. 插件入口函數儘可能使用同步函數,若是爲異步函數,只能使用Task.Run方式裹全部邏輯.
  4. 若是有任何疑問或不一樣意見,請賜教.
相關文章
相關標籤/搜索