Глобальный кеш сборок на .NET Framework

В качестве части установки .NET Framework на компьютере создается центральный репозиторий для хранения сборок .NET, который называется глобальным кешем сборок (Global Assembly Cache — GAC). Глобальный кеш сборок содержит централизованную копию самой платформы .NET Framework, и в него также можно помещать и собственные сборки.

Основным фактором, влияющим на решение, загружать ли сборки в GAC, является поддержка версий. Для сборок в GAC поддержка версий централизуется на уровне машины и управляется администратором. Для сборок за пределами GAC поддержка версий осуществляется на основе приложений, так что каждое приложение само заботится о своих зависимостях и обновлениях (обычно поддерживая собственные копии всех сборок, на которые имеются ссылки).

Глобальный кеш сборок полезен в меньшинстве случаев, когда централизованная поддержка версий на уровне машины по-настоящему выгодна. Например, пусть имеется набор независимых подключаемых модулей, каждый из которых ссылается на некоторые разделяемые сборки. Мы предполагаем, что каждый подключаемый модуль находится в собственном каталоге, и по этой причине существует возможность наличия множества копий какой-то из разделяемых сборок. Далее предположим, что размещающее приложение требует загрузки каждой разделяемой сборки только один раз ради эффективности или совместимости типов. Тогда задача разрешения сборок для размещающего приложения существенно затрудняется, требуя тщательного планирования и понимания тонкостей контекстов загрузки сборок. Более простое решение в этом случае заключается в помещении разделяемых сборок в GAC. Это гарантирует, что среда CLR всегда будет принимать прямые и согласованные решения при разрешении сборок.

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

• Развертывание XCOPY или ClickOnce больше невозможно; для установки приложения потребуются административные привилегии.

• Для обновления сборок в GAC также нужны административные привилегии.

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

• Поддержка версий и выполнение бок о бок требует некоторого планирования, и какая-то ошибка может нарушить работу других приложений.

В качестве положительной стороны, GAC может улучшить показатели времени запуска для очень крупных сборок, т.к. CLR проверяет подписи сборок в GAC только при их установке туда, а не каждый раз, когда сборка загружается. В процентном отношении это имеет значение, если для сборок генерируются образы в машинном коде с помощью инструмента gltg.ехе с выбором неперекрывающихся базовых адресов.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *