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

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

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

程序集保護(hù)：

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

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

程序集合并：

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

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

客戶端更新：

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

程序集存儲(chǔ)分離：

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

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

.net core

在.net core中，這個(gè)機(jī)制也是可以使用的，不過(guò)接口發(fā)生了一點(diǎn)變化：

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

需要說(shuō)明的是，如果是使用 dotnet xxx.dll 的方式運(yùn)行的話，dotnet 程序會(huì)首先通過(guò) xxx.deps.json文件來(lái)獲取所有相關(guān)的依賴性，從而還沒(méi)有進(jìn)入程序就報(bào)錯(cuò)。

可以通過(guò)修改 xxx.deps.json去掉依賴項(xiàng)，或者干脆直接刪掉xxx.deps.json解決這個(gè)問(wèn)題。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。