瞭解程序集如何在C#.NET中加載
我們一直在處理庫和NuGet軟件包。不管是好是壞,高級.NET開發人員都需要了解.NET運行時如何加載程序集。
這些庫依賴於其他流行的庫,並且有很多共享的依賴項。有了足夠大的依賴關係網絡,您最終將陷入衝突或困境。處理此類問題的最佳方法是瞭解該機制在內部的工作方式。
在本文中,您將看到.NET進程如何以及何時加載引用的程序集。
您將瞭解加載了哪個庫版本,當有多個可用版本時會發生什麼,以及爲什麼有時由於版本衝突而出現問題。
您將看到如何調試這些類型的問題,查看程序集綁定日誌(融合日誌)以及一些解決衝突的方法。
程序集,模塊和引用
讓我們從圍繞.NET流程的一些基本術語開始。
一個裝配在.NET是一個DLL或EXE文件。Visual Studio解決方案中的每個項目都被編譯爲一個程序集。
每個程序集可以包含多個模塊,但是實際上,我們幾乎總是在一個程序集中有一個模塊,該模塊的名稱與該程序集相同。
在Visual Studio中啓動進程或單擊F5時,將執行啓動項目程序集。除了.NET Framework或.NET Core程序集之外,它將是第一個加載的程序集。
之後,該過程將根據需要在運行時加載其他程序集。僅當需要調用該程序集的方法或使用該程序集的類型時,它纔會延遲加載程序集。
這裏是爲一個簡單的“ Hello World” .NET Framework項目加載的模塊(出於我們所有的意圖和目的,模塊和程序集都是相同的)。MyStartup.dll是此處的啓動項目:
.NET Core項目啓動時加載的模塊當您從另一個項目引用一個項目時,在構建時,被引用項目的DLL或EXE被複制到啓動項目的Bin文件夾中。
通常是Bin \ Debug或Bin \ Release。在運行時,當您第一次使用引用的項目中的類型時,CLR在應用程序目錄中查找具有與期望的名稱和版本相同的DLL文件。然後將程序集加載到流程中。這也稱爲綁定到裝配件。
這是一個例子:
假設我們有一個名爲MyStartup的簡單控制檯應用程序,它引用了另一個名爲Lib1的項目。MyStartup使用Lib1程序集中的某些類。
在MyStartup中:
class Program
{
static void Main(string[] args)
{
int a = int.Parse(Console.ReadLine());
int b = int.Parse(Console.ReadLine());
Console.WriteLine("A + B = " + Add(a, b));
}
private static int Add(int a, int b)
{
var calculator = new Lib1.Calculator();
return calculator.Sum(a, b);
}
}
在Lib1中:
public class Calculator
{
public int Sum(int a, int b)
{
return a + b;
}
}
輸入Main
方法時,尚未加載Lib1程序集。但是,在輸入Add
方法時,CLR嘗試解析Calculator
類型,找出它在引用的程序集Lib1中,然後嘗試加載該程序集。
.NET中的程序集綁定
當CLR需要加載程序集時,邏輯實際上比在Bin文件夾中查找要複雜一些。這是執行的實際邏輯(有關詳細說明,請參見Microsoft文檔[1]):
1.根據配置文件(app.config或web.config)確定需要加載的程序集的版本。該配置文件的名稱爲(在生成之後) [executable name].exe.config
或web.config
。綁定重定向在這裏發揮了作用(稍後會詳細介紹)。2.查看程序集是否已加載。如果加載了其他版本,則將拋出FileLoadException,除非它是一個可以同時加載多個版本的強命名程序集。3.如果它是強名稱程序集,請檢查全局程序集緩存[2](GAC)。GAC是機器上共享多個應用程序部件的地方。如果需要的話,程序集會緩存。它只能存儲強命名程序集。它可以存儲同一程序集的不同版本。您可以使用gacutil.exe[3]自己將其安裝到GAC 。4.如果它是一個強名稱的程序集,並且配置文件包含<codeBase>
節點,那麼它將檢查那裏的程序集位置。如果該<codeBase>
節點存在並且找不到程序集,FileNotFoundException
則將引發a。5.根據啓發式算法檢查程序集DLL或EXE。此過程稱爲“探測”。算法如下:1.檢查文件夾[application base] / [assembly name].dll
。應用程序庫是應用程序可執行文件所在的位置。通常,您的Bin \ Debug或Bin \ Release文件夾。2.檢查一下 [application base] / [assembly name] / [assembly name].dll
3.如果爲引用的程序集指定了區域性信息,則僅檢查以下目錄: [application base] / [culture] / [assembly name].dll
[application base] / [culture] / [assembly name] / [assembly name].dll
4.如果該<probing>
節點存在於配置文件中,則它將在該privatePath
節點的屬性指定的文件夾中查找程序集。
他們爲什麼要使所有事情變得如此困難,對嗎?
實際上,這種邏輯非常有助於我們發展,而不會使事情變得困難。它的存在是爲了實現一些重要目標:
•爲了確保您引用的是特定的程序集和版本,則將加載該確切版本。否則,將引發異常。而且,如果您知道自己在做什麼,則可以在配置文件中指定覆蓋規則(綁定重定向)。•爲了靈活地在您要加載的程序集中進行。例如,如果要根據不同的區域性(語言)加載不同的程序集,則可以輕鬆地做到這一點。或者,如果您要根據客戶配置加載不同的程序集,那也可以。•爲了安全起見,我們使用了全稱的程序集。他們確保您不能“僞造”程序集。例如,如果某個進程希望加載Lib1 v4.5,那麼您將無法加載具有相同名稱和版本的惡意軟件程序集。加載時會引發異常。這就是爲什麼在計算機上所有進程都共享的GAC只接受強名稱程序集的原因。
在大多數應用程序中,您無需記住程序集加載和探測的複雜邏輯。您無需瞭解或考慮GAC,全名程序集或操作配置文件。
您幾乎根本不需要考慮庫的版本,因爲可能的衝突通過稱爲“綁定重定向”的機制自動解決了。
綁定重定向
如果有一件事對於瞭解這筆交易非常重要,那就是綁定重定向。能夠告訴運行時它將實際加載哪個版本,而不管其引用的版本如何。
這是一個示例:您的流程有兩個項目(模塊):項目A和項目B。項目A引用log4net.dll v1.1,項目B引用log4net.dll v1.2。兩個log4net DLL文件都複製到輸出文件夾,但是隻能有一個log4net.dll文件。
假設複製到輸出文件夾的文件是log4net.dll v1.2。假設到達的第一個代碼是Project A中的代碼,該代碼引用了log4net v1.1。運行時將在輸出文件夾中查找,找到不同版本的log4net,並失敗FileLoadException
。
還有另一種可能。假設首先執行了項目B中的代碼,並且在嘗試使用log4net時,它成功加載了log4net.dll v1.2。片刻之後,Project A中的代碼將嘗試使用log4net v1.1,請參見該程序集已經加載了其他版本,並拋出FileLoadException
。
如果您知道哪個log4net版本將在輸出文件夾中,在這種情況下可以做的就是告訴運行時應該使用哪個版本。只需app.config
在該runtime
部分的文件中添加以下幾行:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
...
<runtime>
...
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="log4net"
publicKeyToken="669e0ddf0bb1aa2a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="1.2.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
...
</configuration>
這意味着,只要運行時想綁定到版本範圍爲0.0.0.0
to的程序集log4net 5.0.0.0
,它就會嘗試綁定到version 1.2.0
。
實際上,您不必手動添加這些重定向,因爲它們是自動添加的。如果轉到啓動項目的“屬性”,則會看到以下設置:
圖片-20200711101325128默認情況下選中此選項。它會自動檢測版本衝突並在.config
文件中生成綁定重定向。
當問題開始發生時
乍一看,綁定重定向可能看起來像是對所有問題的答案,但事實並非如此。使用綁定重定向時,基本上使用的庫版本與預期不同。如果刪除方法怎麼辦?或方法的簽名已更改?在這種情況下,調用該方法時,程序將因運行時錯誤而失敗。畢竟,創建版本是有原因的。
如果確實存在此類問題,則有解決方法。查看我的文章:如何解決.NET引用和NuGet軟件包版本衝突[4]。
故障排除
當您有一個FileLoadException
或類似的東西時,我建議做的第一件事是查看Visual Studio中的“模塊”窗口。在這裏,您將看到所有已加載的模塊,並確定您要加載的程序集是否已加載,使用哪個版本以及從哪個路徑加載。
除此之外,您還可以查看程序集綁定日誌,也稱爲融合日誌。這些日誌將顯示在程序集綁定嘗試過程中到底發生了什麼。您將看到運行時查找的程序集版本,運行時查找的文件夾以及故障點。
有幾種查看融合日誌的方法。首先,您必須啓用它們,因爲默認情況下它們是禁用的。您可以通過將HKLM\Software\Microsoft\Fusion\ForceLog
值設置爲1並將HKLM\Software\Microsoft\Fusion\LogPath
值設置爲來在註冊表中手動啓用它們C:\FusionLogs
。日誌將自動出現。或者,您可以使用Fusion Log Viewer,該軟件應以方式安裝在PC上fuslogvw.exe
。我建議使用“一切窗口”搜索之[5]類的程序來查找它。確保以管理員權限運行融合日誌查看器,以便能夠啓用和禁用日誌。最近更流行的一種更現代的工具是Fusion ++[6]。
邊注
也許您不需要,但是我以前討厭不得不處理這類問題。例如一個邏輯上的問題,讓我構建一些東西,甚至解決一個生產錯誤,但其他問題都好說,唯獨這個……。
在這件事上別無選擇,我不得不艱難地學習程序集綁定的內部工作。我發現,就像其他所有內容一樣,一旦您理解了某些內容,它就會變得不那麼可怕,甚至變得不再那麼有趣了。
因此,我希望本文對您有意義,並會在我走過的道路上爲您提供快速幫助。
References
[1]
Microsoft文檔: https://docs.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies[2]
全局程序集緩存: https://docs.microsoft.com/en-us/dotnet/framework/app-domains/gac[3]
gacutil.exe: https://docs.microsoft.com/en-us/dotnet/framework/tools/gacutil-exe-gac-tool[4]
如何解決.NET引用和NuGet軟件包版本衝突: https://michaelscodingspot.com/how-to-resolve-net-reference-and-nuget-package-version-conflicts/[5]
一切窗口”搜索之: https://www.voidtools.com/[6]
Fusion ++: https://github.com/awaescher/Fusion/