.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. 若是有任何疑问或不一样意见,请赐教.