.NET 4.0 имеет новый GAC, почему?
%windir%\Microsoft.NET\assembly\ новый GAC. Это означает теперь, что мы должны управлять двумя GACs, один для.NET 2.0-3.5 приложения и другой для.NET 4,0 приложения?
Вопрос, почему?
3 ответа
Да, поскольку существует 2 разных Global Assembly Cache (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 {{ 1}} - это среда CLR 2.0. В результате в предыдущих двух выпусках фреймворка не было необходимости разделять GAC. Проблема взлома старых (в этом случае , .NET 2.0) снова появятся в Net Framework 4.0 в , когда была выпущена среда CLR 4.0. Следовательно, во избежание проблем с взаимодействием между CLR 2.0 и CLR 4.0, GAC теперь разделен на частные GAC для каждой среды выполнения.
Поскольку среда CLR обновляется в будущих версиях, вы можете ожидать того же самого. Если изменится только язык, вы можете использовать тот же GAC.
В этом нет большого смысла, исходный GAC уже вполне мог хранить разные версии сборок. И нет особых причин предполагать, что программа когда-либо случайно будет ссылаться на неправильную сборку, все сборки .NET 4 получили [AssemblyVersion] поднятым до 4.0.0.0. Новая функция параллельной обработки в процессе не должна изменить этого.
Я предполагаю: уже было слишком много проектов .NET, которые нарушали правило «никогда не ссылаться ни на что напрямую в GAC». Я видел это на этом сайте несколько раз.
Единственный способ избежать поломки этих проектов: переместить GAC. Обратная совместимость священна в Microsoft.
Я также хотел знать, почему 2 GAC, и нашел следующее объяснение Марка Миллера в разделе комментариев документа .NET 4.0 имеет 2 Global Assembly Cache (GAC) :
Марк Миллер сказал ... 28 июня 2010 г. 12:13 PM
Спасибо за сообщение. «Проблемы с помехами» были намеренно расплывчато. В момент письмо, проблемы все еще были исследовали, но там было ясно было несколько сломанных сценариев.
Например, некоторые приложения используют 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. К сожалению, это не было вариантом для этого выпуска.
Надеюсь, это поможет будущим читателям.