.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.

Версия 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. Проблема взросления (в этом кейс, .NET 2.0) приложения Поверхности в Net Framework 4.0 в какой момент CLR 4.0 выпущен. Следовательно, чтобы избежать помех между CLR 2.0 и CLR 4.0, GAC сейчас разделить на частные GAC для каждого во время выполнения.

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

Answer 2

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

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

Спасибо за пост. «Проблемы вмешательства» было намеренно расплывчато На момент писать, проблемы все еще были исследовали, но там было ясно было несколько сломанных сценариев.

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

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

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

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

Answer 3

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

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

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