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

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

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

程序集保護：

.net程序是非常容易反編譯的，這個特性提供了混淆外的另一個方式。由于動態(tài)調(diào)用的方式下，程序集不需要是原始dll，甚至都不需要存儲在磁盤上?？梢酝ㄟ^直接不讓使用者獲取到程序集的dll的方式防止反編譯。

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

程序集合并：

WPF程序由于使用了反射，使用傳統(tǒng)的ILMerge的方式合并后，由于程序集變化了，往往不能正常工作。

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

客戶端更新：

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

程序集存儲分離：

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

可以將這些程序集集中存儲在獨立的位置。服務文件夾中只發(fā)布我們的業(yè)務程序集，看起來更加清晰，更新也更加方便。

.net core

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

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解決這個問題。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論