[解決済み】.NET 4.0は新しいGACを搭載していますが、なぜですか？

質問

%windir%\Microsoft.NET\assembly\ は、新しい GAC . .NET 2.0-3.5 アプリケーション用と .NET 4.0 アプリケーション用の 2 つの GAC を管理しなければならなくなったということでしょうか。

問題は、なぜか？

どのように解決するのか？

グローバルアセンブリキャッシュ(GAC)は2つあるので、それぞれを個別に管理する必要があります。

.NET Framework 4.0では、GACがいくつか変更されました。GACは2つに分割され、1つは各CLRに対応するようになりました。

.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のものであれば、異なるバージョンのアセンブリを保存する機能があるようです。 古いアプリケーションを壊したくないのだろう。

にてご確認ください。 MSDN 4.0 の GAC の変更について .

たとえば、.NET 1.1と.NET 2.0の両方が同じGACを共有している場合、この共有GACからアセンブリをロードする.NET 1.1アプリケーションは、.NET 2.0アセンブリを取得し、それによって.NET 1.1アプリケーションを破壊できることがあります。

.NETで使用されているCLRのバージョンは フレームワーク2.0と.NETフレームワーク3.5 はCLR 2.0です。この結果 前2作では必要なかった フレームワークのリリースでは、GACを分割する必要があります。 古い（この場合 .NET 2.0の場合）アプリケーション Net Framework 4.0で再浮上。 CLR 4.0がリリースされた時点です。それゆえ との干渉問題を回避するため CLR 2.0とCLR 4.0では、GACは現在 各プライベートGACに分割 ランタイムで使用されます。

今後のバージョンアップでCLRが更新されても、同じことが期待できます。 言語が変わるだけなら、同じGACを使うことができます。