.net加載失敗的程序集實現重新加載

Posted on by

在.net程序中，程序集是Lazy加載的，隻有在用的時候才會去加載，當程序集加載失敗時，會觸發AppDomain.AssemblyResolve的事件，在這個事件中，我們甚至還可以進行補救，從別得地方重新加載程序集。

AppDomain.CurrentDomain.AssemblyResolve += (s, e) =>
{
    byte[] content = getLibBytes(e.Name);
    return Assembly.Load(content);
};

這個功能如果使用起來就非常靈活瞭，它可以控制我們自由控制程序集的加載方式。常用的方法有如下幾個：

程序集保護：

.net程序是非常容易反編譯的，這個特性提供瞭混淆外的另一個方式。由於動態調用的方式下，程序集不需要是原始dll，甚至都不需要存儲在磁盤上。可以通過直接不讓使用者獲取到程序集的dll的方式防止反編譯。

發佈的程序的時候，不直接發佈需要保護的程序集，將程序集加密後發佈，或者直接加密後存儲在服務器上。使用的時候，在AssemblyResolve中獲取加密後的程序集，解密後返回。

程序集合並：

WPF程序由於使用瞭反射，使用傳統的ILMerge的方式合並後，由於程序集變化瞭，往往不能正常工作。

有很多工具，通過將程序集合並到exe的資源文件中，使用的時候，再在ssemblyResolve中從資源文件中獲取程序集返回。

客戶端更新：

CS模式的程序一個不足就是更新不方便，可以將程序集存儲在文件數據庫中，直接更新程序集數據庫就可以很方便的實現程序集更新。

程序集存儲分離：

使用微服務模式時，很多部署在同一個服務器上的服務共用著相同的程序集（第三方的Nuget庫），這些程序集更新頻率很低，並且混在一起存儲使得我們不容易找到業務程序集。

可以將這些程序集集中存儲在獨立的位置。服務文件夾中隻發佈我們的業務程序集，看起來更加清晰，更新也更加方便。

.net core

在.net core中，這個機制也是可以使用的，不過接口發生瞭一點變化：

AssemblyLoadContext.Default.Resolving += (context, assembly) =>
{
    var content = getLibBytes(assembly.FullName);
    return Assembly.Load(content);
};

需要說明的是，如果是使用 dotnet xxx.dll 的方式運行的話，dotnet 程序會首先通過 xxx.deps.json文件來獲取所有相關的依賴性，從而還沒有進入程序就報錯。

可以通過修改 xxx.deps.json去掉依賴項，或者幹脆直接刪掉xxx.deps.json解決這個問題。

以上就是本文的全部內容，希望對大傢的學習有所幫助，也希望大傢多多支持WalkonNet。

推薦閱讀：