依赖文件内容如下.一般位于编译生成目录中
{ "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; } }
安装 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如下
win-x64
win-x32
win-arm
osx-x64
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并运行.
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文件夹中.
当你调用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的简单形式,只是参数不同.官方说明
按照官方提供的默认参数测试,卸载仍然失败.说明这两种方式实现底层应该是不同的.
NFinal2开源框架。https://git.oschina.net/LucasDot/NFinal2/tree/master
到此这篇关于.Net core 的热插拔机制的深入探索及卸载问题求救指南的文章就介绍到这了,更多相关.Net core热插拔机制内容请搜索小牛知识库以前的文章或继续浏览下面的相关文章希望大家以后多多支持小牛知识库!
19.5 热插拔 由于Spring Boot程序只是普通的Java程序,所以JVM热插拔应该是开箱即用的。JVM热插拔在某种程度上受限于能够替换的字节码,为了获得更完整的解决方案,可以使用JRebel或Spring Loaded项目。spring-boot-devtools模块也包含对应用迅速重启的支持。 详细信息请参阅下面的第20章开发者工具和如何“热插拔”部分。
我一直在用Spring Boot做P.O.C。 到目前为止,它运行得非常好,前景看好,但有一个主要缺点:我使用的是嵌入式服务器(即,将web应用程序打包在)中,因此在开发时,每次更改CSS、HTML或JS文件时,我都必须重新构建jar并重新启动服务器。没有热插拔。这确实减慢了UI开发的速度。 我可以想出几个快速修复方法,比如从不同的域中加载静态资源并从本地提供服务,以及类似的其他变体,但是在使用I
本文向大家介绍python中pika模块问题的深入探究,包括了python中pika模块问题的深入探究的使用技巧和注意事项,需要的朋友参考一下 前言 工作中经常用到rabbitmq,而用的语言主要是python,所以也就经常会用到python中的pika模块,但是这个模块的使用,也给我带了很多问题,这里整理一下关于这个模块我在使用过程的改变历程已经中间碰到一些问题的解决方法 关于MQ: MQ全称为
本文向大家介绍深入探究JavaScript中for循环的效率问题及相关优化,包括了深入探究JavaScript中for循环的效率问题及相关优化的使用技巧和注意事项,需要的朋友参考一下 Underscore.js库 你一天(一周)内写了多少个循环了? 这当然无害,但这种写法非常丑而且奇怪,这也不是真正需要抱怨的。但这种写法太平庸了。 你在扩展糟糕的代码,在你抛出一大堆if前,你已经精神错乱了。 我在
本文向大家介绍深入探索Java常量池,包括了深入探索Java常量池的使用技巧和注意事项,需要的朋友参考一下 Java的常量池通常分为两种:静态常量池和运行时常量池 静态常量池:class文件中的常量池,class文件中的常量池包括了字符串(数字)字面值,类和方法的信息,占用了class文件的大部分空间。 运行时常量池:JVM在完成加载类之后将class文件中常量池载入到内存中,并保存在方法区中。平
所以我试着做一个三元搜索。现在,我只处理插入函数。我已经理解了三元搜索的基本思想。我知道一个根节点有3个叶子,如果字符在根之前,它就会在左边,在右边之后,如果它匹配根,它就会在中间的叶子上。因此,我的主要目标是制作一个程序,可以为拼写错误的用户输入的单词提供建议。但现在我只是在做三元搜索。我用trie做了一本字典,用它检查用户输入的单词,以建议下一个最好的选择。但是现在,只是在三进制trie中输入