.NET 4.0には新しいGACがありますが、なぜですか？

%windir%\Microsoft.NET\assembly\新しいGACです。.NET 2.0-3.5アプリケーション用と.NET 4.0アプリケーション用の2つのGACを管理する必要があるということですか。

問題は、なぜですか？

はい、2つの異なるグローバルアセンブリキャッシュ（GAC）があるため、それぞれを個別に管理する必要があります。

.NET Framework 4.0では、GACにいくつかの変更が加えられました。GACは、CLRごとに1つずつ、2つに分割されました。

.NET Framework 2.0と.NET Framework 3.5の両方で使用されるCLRバージョンはCLR 2.0です。以前の2つのフレームワークリリースでは、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でも起こりました。同じCLRからのものである限り、GACには異なるバージョンのアセンブリを格納する機能があるようです。彼らは古いアプリケーションを壊したくありません。

4.0でのGACの変更については、MSDNの次の情報を参照してください。

たとえば、.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です。この結果、以前の2つのフレームワークリリースでは、GACを分割する必要はありませんでした。古い（この場合は.NET 2.0）アプリケーションを破壊する問題は、CLR 4.0がリリースされた時点でNet Framework 4.0に再び現れます。したがって、CLR 2.0とCLR 4.0間の干渉の問題を回避するために、GACはランタイムごとにプライベートGACに分割されるようになりました。

CLRは将来のバージョンで更新されるため、同じことが期待できます。言語のみが変更されている場合は、同じGACを使用できます。

また、なぜGACが2つあるのか知りたいと思っていました。また、.NET 4.0のコメントセクションにあるMark Millerによる次の説明には、グローバルアセンブリキャッシュ（GAC）が2つあることがわかりました。

マークミラーは言った... 2010年6月28日12:13 PM

投稿ありがとうございます。「干渉問題」は意図的に曖昧でした。執筆時点では、問題はまだ調査中ですが、いくつかの壊れたシナリオがあったことは明らかでした。

たとえば、一部のアプリケーションはAssemby.LoadWithPartialNameを使用して、アセンブリの最新バージョンをロードします。最高バージョンがv4でコンパイルされている場合、v2（3.0または3.5）アプリはそれをロードできず、機能するバージョンがあったとしてもアプリがクラッシュします。当初、GACを元の場所に分割しましたが、Windowsのアップグレードシナリオで問題が発生しました。これらは両方とも、すでに出荷された関連コードなので、（バージョン分割されたGACを別の場所に移動しました。

これは、ほとんどのアプリケーションに影響を与えることはなく、メンテナンスの負担もありません。両方の場所は、ネイティブのGAC APIを使用してのみアクセスまたは変更する必要があります。これは、期待どおりにパーティションを処理します。これが発生する場所は、GetCachePathなどのGACのパスを公開するAPIを介して、またはマネージコードに読み込まれたmscorlibのパスを調べることです。

アセンブリIDの一部としてアーキテクチャを導入したときも、v2のリリース時にGACの場所を変更したことは注目に値します。これらはGAC_MSIL、GAC_32、およびGAC_64を追加しましたが、すべて％windir％\ assemblyにあります。残念ながら、それはこのリリースではオプションではありませんでした。

それが将来の読者に役立つことを願っています。

あまり意味がありません。元のGACは、さまざまなバージョンのアセンブリを格納する機能をすでに備えていました。そして、プログラムが誤って間違ったアセンブリを参照することを想定する理由はほとんどありません。すべての.NET 4アセンブリが[AssemblyVersion]を4.0.0.0に引き上げました。新しいインプロセスサイドバイサイド機能はこれを変更しないでください。

私の推測では、「GACで直接何かを参照しない」というルールに違反する.NETプロジェクトはすでに多すぎます。このサイトで何度か見たことがあります。

これらのプロジェクトの中断を回避する唯一の方法は、GACを移動することです。マイクロソフトでは、逆互換性が神聖です。