Первым шагом при установке сборок в GAC является назначение им строгих имен. После этого сборку можно установить, используя инструмент командной строки .NET под названием gacutil:
1 |
gacutil /i MyAssembly.dll |
Если сборка уже существует в GAC с тем же самым открытым ключом и версией, она обновляется. Предварительного удаления старой сборки в этом случае не требуется.
Ниже показано, как удалить сборку:
1 |
gacutil /u MyAssembly |
Установку сборок в GAC можно задать как часть проекта установки в Visual Studio.
Запуск gacutil с переключателем /l позволяет получить список всех сборок в GAC. То же самое можно сделать с помощью оснастки mscorcfg консоли ММС. После загрузки сборки в GAC приложения могут ссылаться на нее, не нуждаясь в локальной копии этой сборки.
Если локальная копия присутствует, она игнорируется в пользу образа из GAC. Это означает, что сослаться или протестировать перекомпилированную версию сборки можно, только лишь обновив ее в GAC. Это остается справедливым при условии предохранения версии и удостоверения сборки.
GAC и поддержка версий
Изменение атрибута сборки AssemblyVersion дает совершенно новое удостоверение. В целях иллюстрации представим, что вы написали сборку utils, задали ей версию 1.0, назначили ей строгое имя и затем установили ее в GAC. Предположим, что позже вы добавили в сборку несколько новых средств, изменили ее версию на 1.1, перекомпилировали сборку и переустановили ее в GAC. Вместо переписывания исходной сборки GAC теперь содержит сборки обеих версий. Это означает следующее:
• при компиляции другого приложения, использующего сборку utils, можно выбирать, на какую версию ссылаться;
• любое приложение, ранее скомпилированное со ссылкой на сборку utils версии 1.0, продолжит на нее ссылаться.
Это называется выполнением бок о бок. Выполнение бок о бок предотвращает проблему “ада DLL» (DLL hell), которая в противном случае могла бы возникла, когда разделяемая сборка обновляется односторонне: приложения, разработанные для предыдущей версии сборки, могут неожиданно отказать.
Однако сложность возникает, когда требуется применить исправления ошибок или незначительные обновления к существующим сборкам. В такой ситуации существуют два варианта для действий:
• переустановить исправленную сборку в GAC с тем же самым номером версии;
• скомпилировать исправленную сборку с новым номером версии и установить ее в GAC.
Сложность первого варианта связана с невозможностью избирательного применения обновлений к определенным приложениям. Обновления можно применить или ко всем приложениям, или не применять вообще. Сложность второго варианта заключается в том, что приложения не смогут нормально пользоваться более новой сборкой без перекомпиляции. Существует обходной путь: можно создать политику издателя, разрешающую перенаправление версий сборки, но за счет увеличения сложности развертывания.
Выполнение бок о бок хорошо подходит для смягчения некоторых проблем, связанных с разделяемыми сборками. Если вы вообще не будете применять GAC, вместо этого позволив каждому приложению поддерживать собственную копию сборки utils, то устраните все проблемы, связанные с разделяемыми сборками!