.net載入失敗的程式集重新載入
在.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中從資原始檔中獲取程式集返回。具體可以參看我之前的文章:ofollow,noindex" target="_blank">使用LibZ合併.Net程式集
客戶端更新:
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解決這個問題。