.NET 4.0有一個新的GAC，為什么？

Question

%windir%\\Microsoft.NET\\assembly\\是新的GAC 。 這是否意味着現在我們必須管理兩個GAC，一個用於.NET 2.0-3.5應用程序，另一個用於.NET 4.0應用程序？

問題是，為什么？

Answer 1

是的，因為有2個不同的全局程序集緩存（GAC），您必須單獨管理它們中的每一個。

在.NET Framework 4.0中，GAC經歷了一些更改。 GAC分為兩個，每個CLR一個。

用於.NET Framework 2.0和.NET Framework 3.5的CLR版本是CLR 2.0。 前兩個框架​​版本中沒有必要拆分GAC。 在Net Framework 4.0中破壞舊應用程序的問題。

為了避免CLR 2.0和CLR 4.0之間的問題，GAC現在分為每個運行時的私有GAC。主要的變化是CLR v2.0應用程序現在無法在GAC中看到CLR v4.0程序集。

資源

為什么？

這似乎是因為.NET 4.0中存在CLR更改，而不是2.0到3.5。 1.1到2.0 CLR也發生了同樣的事情。 似乎GAC能夠存儲不同版本的程序集，只要它們來自同一個CLR。 他們不想破壞舊的應用程序。

請參閱MSDN中有關4.0中GAC更改的以下信息。

例如，如果.NET 1.1和.NET 2.0共享相同的GAC，則從此共享GAC加載程序集的.NET 1.1應用程序可能會獲得.NET 2.0程序集，從而破壞.NET 1.1應用程序

用於.NET Framework 2.0和.NET Framework 3.5的CLR版本是CLR 2.0。 因此，前兩個框架​​版本中沒有必要拆分GAC。 破解舊版本（在本例中為.NET 2.0）應用程序的問題在Net Framework 4.0中重新出現，此時CLR 4.0已發布。 因此，為了避免CLR 2.0和CLR 4.0之間的干擾問題，GAC現在分為每個運行時的私有GAC。

隨着CLR在未來版本中的更新，您可以期待同樣的事情。 如果只有語言更改，那么您可以使用相同的GAC。

Answer 2

我還想知道為什么2 GAC並且發現Mark Miller在.NET 4.0的評論部分中有以下解釋 有2個全局程序集緩存（GAC） ：

馬克米勒說... 2010年6月28日下午12:13

謝謝你的帖子。 “干擾問題”故意模糊不清。 在撰寫本文時，問題仍在調查中，但很明顯有幾個破碎的情景。

例如，某些應用程序使用Assemby.LoadWithPartialName來加載程序集的最高版本。 如果最高版本是使用v4編譯的，那么v2（3.0或3.5）應用程序無法加載它，並且應用程序會崩潰，即使有一個版本可行。 最初，我們在其原始位置下划分了GAC，但這導致了Windows升級方案的一些問題。 這兩個都涉及已經發布的代碼，因此我們將（版本分區的GAC）移動到另一個地方。

這不會對大多數應用程序產生任何影響，也不會增加任何維護負擔。 只應使用本機GAC API訪問或修改這兩個位置，本地GAC API按預期處理分區。 它所代表的地方是通過API公開GAC的路徑（如GetCachePath），或檢查加載到托管代碼中的mscorlib的路徑。

值得注意的是，當我們將架構作為裝配標識的一部分引入時，我們在發布v2時修改了GAC位置。 那些添加了GAC_MSIL，GAC_32和GAC_64，盡管它們仍然在％windir％\\ assembly下。 不幸的是，這不是這個版本的選項。

希望它能幫助未來的讀者。

Answer 3

它沒有多大意義，原始的GAC已經能夠存儲不同版本的程序集。 並且沒有理由認為程序會偶然引用錯誤的程序集，所有.NET 4程序集都會使[AssemblyVersion]達到4.0.0.0。 新的進程內並排功能不應改變這一點。

我的猜測：已經有太多的.NET項目打破了“永遠不會引用GAC中的任何內容”規則。 我已經在這個網站上看了好幾次。

只有一種方法可以避免破壞這些項目：移動GAC。 Back-compat在微軟是神聖的。