Почему .NET 4.0 имеет новый GAC, почему?

Ответ 1

Да, поскольку есть два разных Глобального сборочного кэша (GAC), вам придется управлять каждым из них индивидуально.

В .NET Framework 4.0 GAC прошел несколько изменений. GAC был разделен на два, по одному для каждой CLR.

Версия CLR, используемая как для .NET Framework 2.0, так и для .NET Framework 3.5, представляет собой CLR 2.0. В предыдущих двух релизах системы не было необходимости разделить GAC. Проблема взлома старых приложений в Net Framework 4.0.

Чтобы избежать проблем между CLR 2.0 и CLR 4.0, GAC теперь разделяется на частные GAC для каждой среды выполнения. Основное изменение заключается в том, что приложения CLR v2.0 теперь не могут видеть сборки CLR v4.0 в GAC.

Источник

Почему?

Кажется, это связано с изменением CLR в .NET 4.0, но не с 2.0 до 3.5. То же самое произошло с 1.1 до 2.0 CLR. Кажется, что GAC имеет возможность хранить различные версии сборок, если они принадлежат к одной и той же CLR. Они не хотят разорвать старые приложения.

См. следующую информацию в MSDN о изменениях GAC в 4.0.

Например, если и .NET 1.1, и .NET 2.0 поделились одним и тем же GAC, тогда приложение .NET 1.1, загрузив сборку из этого общего GAC, могло получить сборки .NET 2.0, тем самым нарушив приложение .NET 1.1

Версия CLR, используемая для .NET. Framework 2.0 и .NET Framework 3.5 CLR 2.0. В результате этого не было необходимости в предыдущих двух чтобы разделить GAC. Проблема взлома более старых (в этом case,.NET 2.0) resurfaces в Net Framework 4.0 на который выдает CLR 4.0. Следовательно, во избежание проблем с помехами между CLR 2.0 и CLR 4.0, теперь GAC делиться на частные GAC для каждого во время выполнения.

По мере обновления CLR в будущих версиях вы можете ожидать то же самое. Если изменяется только язык, вы можете использовать тот же GAC.

Ответ 2

Я также хотел знать, почему 2 GAC и нашел следующее объяснение Марка Миллера в раздел комментариев .NET 4.0 имеет 2 глобальных сборочных кэш (GAC):

Марк Миллер сказал... 28 июня 2010 г. 12:13

Спасибо за должность. "Проблемы с помехами" намеренно расплывчатым. В момент Письмо, все еще исследовали, но было ясно были несколько разбитых сценариев.

Например, некоторые приложения используют Assemby.LoadWithPartialName для загрузки самая высокая версия сборки. Если самая высокая версия была скомпилирована с v4, то приложение v2 (3.0 или 3.5) могло бы не загружать его, и приложение будет разбиваться, даже если бы была версия, которая будет работать. Первоначально мы разделял GAC под его первоначальное местоположение, но это вызвало некоторые проблемы с обновлением окон сценарии. Оба из них связаны с кодом которые уже были отправлены, поэтому мы переехали наш (с расширением GAC для другое место.

Это не должно влиять на большинство приложений и не добавляет никаких бремя обслуживания. Оба местоположения должен быть доступен или изменен используя собственные API GAC, которые с разбиением, как ожидалось. места, где это поверхность через API, которые раскрывают пути GAC, например GetCachePath, или изучение пути загрузки mscorlib в управляемый код.

Стоит отметить, что мы модифицировали GAC места, когда мы выпустили v2 когда мы представили архитектуру как часть идентификатора сборки. Те добавлены GAC_MSIL, GAC_32 и GAC_64, хотя все еще % Windir%\сборка. К сожалению, это не был вариантом для этого выпуска.

Надеюсь, это поможет будущим читателям.

Ответ 3

Это не имеет большого смысла, оригинальный GAC уже вполне способен хранить разные версии сборок. И нет оснований полагать, что программа когда-либо случайно ссылается на неправильную сборку, все сборки .NET 4 получили [AssemblyVersion], наложенную до 4.0.0.0. Новая функция сбоку в процессе не должна меняться.

Мое предположение: там было слишком много проектов .NET, которые нарушили правило "никогда не ссылаться ни на что в GAC напрямую". Я видел это на этом сайте несколько раз.

Только один способ избежать нарушения этих проектов: переместить GAC. Back-compat является священной в Microsoft.