.NET 4.0 には新しい 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 でも同じことが起きました。GAC には、同じ CLR からのものであれば、異なるバージョンのアセンブリを保存できる機能があるようです。古いアプリケーションを壊したくないのです。

以下の情報を参照してください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 を使用できます。