通常狀況下,一個 .NET 程序集加載到程序中之後,它的類型信息以及原生代碼等數據會一直保留在內存中,.NET 運行時沒法回收它們,若是咱們要實現插件熱加載 (例如 Razor 或 Aspx 模版的熱更新) 則會形成內存泄漏。在以往,咱們可使用 .NET Framework 的 AppDomain 機制,或者使用解釋器 (有必定的性能損失),或者在編譯必定次數之後重啓程序 (Asp.NET 的 numRecompilesBeforeAppRestart) 來避免內存泄漏。html
由於 .NET Core 不像 .NET Framework 同樣支持動態建立與卸載 AppDomain,因此一直都沒有好的方法實現插件熱加載,好消息是,.NET Core 從 3.0 開始支持了可回收程序集 (Collectible Assembly),咱們能夠建立一個可回收的 AssemblyLoadContext,用它來加載與卸載程序集。關於 AssemblyLoadContext 的介紹與實現原理能夠參考 yoyofx 的文章 與 個人文章。git
本文會經過一個 180 行左右的示例程序,介紹如何使用 .NET Core 3.0 的 AssemblyLoadContext 實現插件熱加載,程序同時使用了 Roslyn 實現動態編譯,最終效果是改動插件代碼後能夠自動更新到正在運行的程序當中,而且不會形成內存泄漏。github
首先咱們來看看完整源代碼與文件夾結構,源代碼分爲兩部分,一部分是宿主,負責編譯與加載插件,另外一部分則是插件,後面會對源代碼的各個部分做出詳細講解。web
文件夾結構:app
Program.cs 的內容:框架
using Microsoft.CodeAnalysis; using Microsoft.CodeAnalysis.CSharp; using Microsoft.CodeAnalysis.CSharp.Syntax; using System; using System.Collections.Generic; using System.IO; using System.Linq; using System.Reflection; using System.Runtime.Loader; using System.Threading; namespace Common { public interface IPlugin : IDisposable { string GetMessage(); } } namespace Host { using Common; internal class PluginController : IPlugin { private List<Assembly> _defaultAssemblies; private AssemblyLoadContext _context; private string _pluginName; private string _pluginDirectory; private volatile IPlugin _instance; private volatile bool _changed; private object _reloadLock; private FileSystemWatcher _watcher; public PluginController(string pluginName, string pluginDirectory) { _defaultAssemblies = AssemblyLoadContext.Default.Assemblies .Where(assembly => !assembly.IsDynamic) .ToList(); _pluginName = pluginName; _pluginDirectory = pluginDirectory; _reloadLock = new object(); ListenFileChanges(); } private void ListenFileChanges() { Action<string> onFileChanged = path => { if (Path.GetExtension(path).ToLower() == ".cs") _changed = true; }; _watcher = new FileSystemWatcher(); _watcher.Path = _pluginDirectory; _watcher.IncludeSubdirectories = true; _watcher.NotifyFilter = NotifyFilters.LastWrite | NotifyFilters.FileName; _watcher.Changed += (sender, e) => onFileChanged(e.FullPath); _watcher.Created += (sender, e) => onFileChanged(e.FullPath); _watcher.Deleted += (sender, e) => onFileChanged(e.FullPath); _watcher.Renamed += (sender, e) => { onFileChanged(e.FullPath); onFileChanged(e.OldFullPath); }; _watcher.EnableRaisingEvents = true; } private void UnloadPlugin() { _instance?.Dispose(); _instance = null; _context?.Unload(); _context = null; } private Assembly CompilePlugin() { var binDirectory = Path.Combine(_pluginDirectory, "bin"); var dllPath = Path.Combine(binDirectory, $"{_pluginName}.dll"); if (!Directory.Exists(binDirectory)) Directory.CreateDirectory(binDirectory); if (File.Exists(dllPath)) { File.Delete($"{dllPath}.old"); File.Move(dllPath, $"{dllPath}.old"); } var sourceFiles = Directory.EnumerateFiles( _pluginDirectory, "*.cs", SearchOption.AllDirectories); var compilationOptions = new CSharpCompilationOptions( OutputKind.DynamicallyLinkedLibrary, optimizationLevel: OptimizationLevel.Debug); var references = _defaultAssemblies .Select(assembly => assembly.Location) .Where(path => !string.IsNullOrEmpty(path) && File.Exists(path)) .Select(path => MetadataReference.CreateFromFile(path)) .ToList(); var syntaxTrees = sourceFiles .Select(p => CSharpSyntaxTree.ParseText(File.ReadAllText(p))) .ToList(); var compilation = CSharpCompilation.Create(_pluginName) .WithOptions(compilationOptions) .AddReferences(references) .AddSyntaxTrees(syntaxTrees); var emitResult = compilation.Emit(dllPath); if (!emitResult.Success) { throw new InvalidOperationException(string.Join("\r\n", emitResult.Diagnostics.Where(d => d.WarningLevel == 0))); } //return _context.LoadFromAssemblyPath(Path.GetFullPath(dllPath)); using (var stream = File.OpenRead(dllPath)) { var assembly = _context.LoadFromStream(stream); return assembly; } } private IPlugin GetInstance() { var instance = _instance; if (instance != null && !_changed) return instance; lock (_reloadLock) { instance = _instance; if (instance != null && !_changed) return instance; UnloadPlugin(); _context = new AssemblyLoadContext( name: $"Plugin-{_pluginName}", isCollectible: true); var assembly = CompilePlugin(); var pluginType = assembly.GetTypes() .First(t => typeof(IPlugin).IsAssignableFrom(t)); instance = (IPlugin)Activator.CreateInstance(pluginType); _instance = instance; _changed = false; } return instance; } public string GetMessage() { return GetInstance().GetMessage(); } public void Dispose() { UnloadPlugin(); _watcher?.Dispose(); _watcher = null; } } internal class Program { static void Main(string[] args) { using (var controller = new PluginController("MyPlugin", "../guest")) { bool keepRunning = true; Console.CancelKeyPress += (sender, e) => { e.Cancel = true; keepRunning = false; }; while (keepRunning) { try { Console.WriteLine(controller.GetMessage()); } catch (Exception ex) { Console.WriteLine($"{ex.GetType()}: {ex.Message}"); } Thread.Sleep(1000); } } } } }
host.csproj 的內容:編輯器
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="3.3.1" /> </ItemGroup> </Project>
Plugin.cs 的內容:函數
using System; using Common; namespace Guest { public class MyPlugin : IPlugin { public MyPlugin() { Console.WriteLine("MyPlugin loaded"); } public string GetMessage() { return "Hello 1"; } public void Dispose() { Console.WriteLine("MyPlugin unloaded"); } } }
進入 pluginexample/host
下運行 dotnet run
便可啓動宿主程序,這時宿主程序會自動編譯與加載插件,檢測插件文件的變化並在變化時從新編譯加載。你能夠在運行後修改 pluginexample/guest/Plugin.cs
中的 Hello 1
爲 Hello 2
,以後能夠看到相似如下的輸出:性能
MyPlugin loaded Hello 1 Hello 1 Hello 1 MyPlugin unloaded MyPlugin loaded Hello 2 Hello 2
咱們能夠看到程序自動更新並執行修改之後的代碼,若是你有興趣還能夠測試插件代碼語法錯誤時會出現什麼。測試
接下來是對宿主的源代碼中各個部分的詳細講解:
public interface IPlugin : IDisposable { string GetMessage(); }
這是插件項目須要的實現接口,宿主項目在編譯插件後會尋找程序集中實現 IPlugin 的類型,建立這個類型的實例而且使用它,建立插件時會調用構造函數,卸載插件時會調用 Dispose 方法。若是你用過 .NET Framework 的 AppDomain 機制可能會想是否須要 Marshalling 處理,答案是不須要,.NET Core 的可回收程序集會加載到當前的 AppDomain 中,回收時須要依賴 GC 清理,好處是使用簡單而且運行效率高,壞處是 GC 清理有延遲,只要有一個插件中類型的實例沒有被回收則插件程序集使用的數據會一直殘留,致使內存泄漏。
internal class PluginController : IPlugin { private List<Assembly> _defaultAssemblies; private AssemblyLoadContext _context; private string _pluginName; private string _pluginDirectory; private volatile IPlugin _instance; private volatile bool _changed; private object _reloadLock; private FileSystemWatcher _watcher;
這是管理插件的代理類,在內部它負責編譯與加載插件,而且把對 IPlugin 接口的方法調用轉發到插件的實現中。類成員包括默認 AssemblyLoadContext 中的程序集列表 _defaultAssemblies
,用於加載插件的自定義 AssemblyLoadContext _context
,插件名稱與文件夾,插件實現 _instance
,標記插件文件是否已改變的 _changed
,防止多個線程同時編譯加載插件的 _reloadLock
,與監測插件文件變化的 _watcher
。
public PluginController(string pluginName, string pluginDirectory) { _defaultAssemblies = AssemblyLoadContext.Default.Assemblies .Where(assembly => !assembly.IsDynamic) .ToList(); _pluginName = pluginName; _pluginDirectory = pluginDirectory; _reloadLock = new object(); ListenFileChanges(); }
構造函數會從 AssemblyLoadContext.Default.Assemblies
中獲取默認 AssemblyLoadContext 中的程序集列表,包括宿主程序集、System.Runtime 等,這個列表會在 Roslyn 編譯插件時使用,表示插件編譯時須要引用哪些程序集。以後還會調用 ListenFileChanges
監聽插件文件是否有改變。
private void ListenFileChanges() { Action<string> onFileChanged = path => { if (Path.GetExtension(path).ToLower() == ".cs") _changed = true; }; _watcher = new FileSystemWatcher(); _watcher.Path = _pluginDirectory; _watcher.IncludeSubdirectories = true; _watcher.NotifyFilter = NotifyFilters.LastWrite | NotifyFilters.FileName; _watcher.Changed += (sender, e) => onFileChanged(e.FullPath); _watcher.Created += (sender, e) => onFileChanged(e.FullPath); _watcher.Deleted += (sender, e) => onFileChanged(e.FullPath); _watcher.Renamed += (sender, e) => { onFileChanged(e.FullPath); onFileChanged(e.OldFullPath); }; _watcher.EnableRaisingEvents = true; }
這個方法建立了 FileSystemWatcher
,監聽插件文件夾下的文件是否有改變,若是有改變而且改變的是 C# 源代碼 (.cs 擴展名) 則設置 _changed
成員爲 true,這個成員標記插件文件已改變,下次訪問插件實例的時候會觸發從新加載。
你可能會有疑問,爲何不在文件改變後馬上觸發從新加載插件,一個緣由是部分文件編輯器的保存文件實現可能會致使改變的事件連續觸發幾回,延遲觸發能夠避免編譯屢次,另外一個緣由是編譯過程當中出現的異常能夠傳遞到訪問插件實例的線程中,方便除錯與調試 (儘管使用 ExceptionDispatchInfo 也能夠作到)。
private void UnloadPlugin() { _instance?.Dispose(); _instance = null; _context?.Unload(); _context = null; }
這個方法會卸載已加載的插件,首先調用 IPlugin.Dispose
通知插件正在卸載,若是插件建立了新的線程能夠在 Dispose
方法中中止線程避免泄漏,而後調用 AssemblyLoadContext.Unload
容許 .NET Core 運行時卸載這個上下文加載的程序集,程序集的數據會在 GC 檢測到全部類型的實例都被回收後回收 (參考文章開頭的連接)。
private Assembly CompilePlugin() { var binDirectory = Path.Combine(_pluginDirectory, "bin"); var dllPath = Path.Combine(binDirectory, $"{_pluginName}.dll"); if (!Directory.Exists(binDirectory)) Directory.CreateDirectory(binDirectory); if (File.Exists(dllPath)) { File.Delete($"{dllPath}.old"); File.Move(dllPath, $"{dllPath}.old"); } var sourceFiles = Directory.EnumerateFiles( _pluginDirectory, "*.cs", SearchOption.AllDirectories); var compilationOptions = new CSharpCompilationOptions( OutputKind.DynamicallyLinkedLibrary, optimizationLevel: OptimizationLevel.Debug); var references = _defaultAssemblies .Select(assembly => assembly.Location) .Where(path => !string.IsNullOrEmpty(path) && File.Exists(path)) .Select(path => MetadataReference.CreateFromFile(path)) .ToList(); var syntaxTrees = sourceFiles .Select(p => CSharpSyntaxTree.ParseText(File.ReadAllText(p))) .ToList(); var compilation = CSharpCompilation.Create(_pluginName) .WithOptions(compilationOptions) .AddReferences(references) .AddSyntaxTrees(syntaxTrees); var emitResult = compilation.Emit(dllPath); if (!emitResult.Success) { throw new InvalidOperationException(string.Join("\r\n", emitResult.Diagnostics.Where(d => d.WarningLevel == 0))); } //return _context.LoadFromAssemblyPath(Path.GetFullPath(dllPath)); using (var stream = File.OpenRead(dllPath)) { var assembly = _context.LoadFromStream(stream); return assembly; } }
這個方法會調用 Roslyn 編譯插件代碼到 DLL,並使用自定義的 AssemblyLoadContext 加載編譯後的 DLL。首先它須要刪除原有的 DLL 文件,由於卸載程序集有延遲,原有的 DLL 文件在 Windows 系統上極可能會刪除失敗並提示正在使用,因此須要先重命名並在下次刪除。接下來它會查找插件文件夾下的全部 C# 源代碼,用 CSharpSyntaxTree
解析它們,並用 CSharpCompilation
編譯,編譯時引用的程序集列表是構造函數中取得的默認 AssemblyLoadContext 中的程序集列表 (包括宿主程序集,這樣插件代碼纔可使用 IPlugin 接口)。編譯成功後會使用自定義的 AssemblyLoadContext 加載編譯後的 DLL 以支持卸載。
這段代碼中有兩個須要注意的部分,第一個部分是 Roslyn 編譯失敗時不會拋出異常,編譯後須要判斷 emitResult.Success
並從 emitResult.Diagnostics
找到錯誤信息;第二個部分是加載插件程序集必須使用 AssemblyLoadContext.LoadFromStream
從內存數據加載,若是使用 AssemblyLoadContext.LoadFromAssemblyPath
那麼下次從同一個路徑加載時仍然會返回第一次加載的程序集,這多是 .NET Core 3.0 的實現問題而且有可能在之後的版本修復。
private IPlugin GetInstance() { var instance = _instance; if (instance != null && !_changed) return instance; lock (_reloadLock) { instance = _instance; if (instance != null && !_changed) return instance; UnloadPlugin(); _context = new AssemblyLoadContext( name: $"Plugin-{_pluginName}", isCollectible: true); var assembly = CompilePlugin(); var pluginType = assembly.GetTypes() .First(t => typeof(IPlugin).IsAssignableFrom(t)); instance = (IPlugin)Activator.CreateInstance(pluginType); _instance = instance; _changed = false; } return instance; }
這個方法是獲取最新插件實例的方法,若是插件實例已建立而且文件沒有改變,則返回已有的實例,不然卸載原有的插件、從新編譯插件、加載並生成實例。注意 AssemblyLoadContext 類型在 netstandard (包括 2.1) 中是 abstract 類型,不能直接建立,只有 netcoreapp3.0 才能夠直接建立 (目前也只有 .NET Core 3.0 支持這項機制),若是須要支持可回收則建立時須要設置 isCollectible 參數爲 true,由於支持可回收會讓 GC 掃描對象時作一些額外的工做因此默認不啓用。
public string GetMessage() { return GetInstance().GetMessage(); }
這個方法是代理方法,會獲取最新的插件實例並轉發調用參數與結果,若是 IPlugin 有其餘方法也能夠像這個方法同樣寫。
public void Dispose() { UnloadPlugin(); _watcher?.Dispose(); _watcher = null; }
這個方法支持主動釋放 PluginController,會卸載已加載的插件而且中止監聽插件文件。由於 PluginController 沒有直接管理非託管資源,而且 AssemblyLoadContext 的析構函數 會觸發卸載,因此 PluginController 不須要提供析構函數。
static void Main(string[] args) { using (var controller = new PluginController("MyPlugin", "../guest")) { bool keepRunning = true; Console.CancelKeyPress += (sender, e) => { e.Cancel = true; keepRunning = false; }; while (keepRunning) { try { Console.WriteLine(controller.GetMessage()); } catch (Exception ex) { Console.WriteLine($"{ex.GetType()}: {ex.Message}"); } Thread.Sleep(1000); } } }
主函數建立了 PluginController 實例並指定了上述的 guest 文件夾爲插件文件夾,以後每隔 1 秒調用一次 GetMessage 方法,這樣插件代碼改變的時候咱們能夠從控制檯輸出中觀察的到,若是插件代碼包含語法錯誤則調用時會拋出異常,程序會繼續運行並在下一次調用時從新嘗試編譯與加載。
本文的介紹就到此爲止了,在本文中咱們看到了一個最簡單的 .NET Core 3.0 插件熱加載實現,這個實現仍然有不少須要改進的地方,例如如何管理多個插件、怎麼在重啓宿主程序後避免從新編譯全部插件,編譯的插件代碼如何調試等,若是你有興趣能夠解決它們,作一個插件系統嵌入到你的項目中,或者寫一個新的框架。
關於 ZKWeb,3.0 會使用了本文介紹的機制實現插件熱加載,但由於我目前已經退出 IT 行業,全部開發都是業餘空閒時間作的,因此基本上不會有很大的更新,ZKWeb 更多的會做爲一個框架的實現參考。此外,我正在使用 C++ 編寫 HTTP 框架 cpv-framework,主要着重性能 (吞吐量是 .NET Core 3.0 的兩倍以上,與 actix-web 持平),目前尚未正式發佈。
關於書籍,出版社約定 11 月但目前尚未讓我看修改過的稿件 (儘管我問的時候會回答),因此很大可能會繼續延期,抱歉讓期待出版的同窗們久等了,書籍目前仍是基於 .NET Core 2.2 而不是 .NET Core 3.0。