.NET 4.0 имеет новый GAC, почему?
%windir%\Microsoft.NET\assembly\ это новый GAC. Значит ли это, что теперь нам нужно управлять двумя GAC, один для приложений.NET 2.0-3.5, а другой для приложений.NET 4.0?
Вопрос в том, почему?
4 ответа
Да, поскольку существует 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.
Я также хотел знать, почему 2 GAC и нашел следующее объяснение Марка Миллера в разделе комментариев .NET 4.0 имеет 2 Global Assembly Cache (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%\assembly. К сожалению, это не вариант для этого выпуска.
Надеюсь, это поможет будущим читателям.
Это не имеет большого смысла, оригинальный GAC уже был вполне способен хранить разные версии сборок. И нет никаких оснований предполагать, что программа когда-либо будет случайно ссылаться на неправильную сборку, все сборки.NET 4 получили [AssemblyVersion] повышенную до 4.0.0.0. Новая функция в процессе работы не должна изменить это.
Мое предположение: уже было слишком много проектов.NET, которые нарушили правило "никогда не ссылаться на что-либо непосредственно в GAC". Я видел это на этом сайте несколько раз.
Единственный способ избежать разрушения этих проектов: перенести GAC. Back-compat является священным в Microsoft.
В .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.