И кроме того, существуют случаи, когда нужно использовать глобальный кеш сборки или где его нельзя использовать?
Каковы преимущества и недостатки использования GAC?
Ответ 1
- Загрузка сборок из GAC означает меньшие накладные расходы и безопасность, что ваше приложение всегда будет загружать правильную версию библиотеки .NET.
- Вам не нужно собирать узлы, которые находятся за пределами GAC, потому что почти не будет увеличения производительности, во многих случаях даже потери производительности.
- Вы уже используете GAC, потому что все стандартные сборки .NET на самом деле находятся в GAC и ngened (во время установки).
- Использование GAC для ваших собственных библиотек увеличивает сложность развертывания, я постараюсь избежать его любой ценой.
- Ваши пользователи должны быть зарегистрированы в качестве администраторов во время установки, если вы хотите что-то вставить в GAC, что является проблемой для многих типов приложений.
Итак, суммируем все, начинаем просто, и если вы позже увидите существенный прирост производительности, если вы поместите свои сборки в GAC и NGEN их, пойдите для этого, иначе не беспокойтесь. GAC больше подходит для фреймворков, где есть ожидание того, что библиотека будет доступна для других приложений, в 99% случаев она вам не понадобится.
Ответ 2
Преимущество:
- Только одно место для обновления сборки
- Вы используете немного меньше места на жестком диске.
Недостаток:
- Если вам нужно обновить только один веб-сайт, вы не сможете. Вы можете закончить работу с другими веб-сайтами в поврежденном веб-сервере.
Рекомендация: Оставьте GAC для MS и друзей. Гигабайт сейчас очень дешев.
Ответ 3
GAC также может использоваться сборками, требующими повышенных разрешений для выполнения привилегированных операций от имени менее доверенного кода (например, приложения ASP.NET с частичным доверием).
Например, скажем, что у вас есть приложение ASP.NET с частичным доверием, которое должно выполнять задачу, требующую повышенных привилегий, то есть полного доверия. Решение состоит в том, чтобы поместить код, который требует повышенных привилегий, в отдельную сборку. Сборка отмечена атрибутом AllowPartiallyTrustedCallers
, а класс, содержащий привилегированную логику, помечен атрибутом PermissionSet, что-то вроде этого:
[PermissionSet(SecurityAction.Assert, Unrestricted=true)]
Нашей сборке будет присвоено сильное имя (подписанное), а затем развернуто в GAC.
Теперь наши частично доверенные приложения могут использовать доверенную сборку в GAC для выполнения определенного и узкого набора привилегированных операций без потери преимуществ частичного доверия.
Ответ 4
Когда я сам изучил эту тему, я обнаружил, что Демистификация глобального сборочного кэша .NET Jeremiah Talkar мне очень помог.
Ответ 5
Если вы отправляете многоразовую библиотеку, состоящую из нескольких сборок, но лишь немногие из них образуют фасад, вы можете рассмотреть возможность установки сборок в GAC, если пакет установлен на компьютеры разработчиков.
Представьте, вы отправляете 6 сборок, и только одна из этих 6 сборок содержит фасад, т.е. другие 5 используются только самим фасадом. Вы отправляете:
- MyProduct.Facade.dll - единственный компонент, предназначенный для использования разработчиками
- MyProduct.Core.dll - используется MyProduct.Facade.dll, но не предназначен для использования разработчиками.
- MyProduct.Component1.dll - тот же
- MyProduct.Component2.dll - тот же
- ThirdParty.Lib1.dll - сторонняя библиотека, используемая MyProduct.Component1.dll
- ThirdParty.Lib2.dll - тот же
- и др.
Разработчики, использующие ваш проект, хотели бы ссылаться только на MyProduct.Facade.dll в своих проектах. Но когда их проект запускается, он должен иметь возможность загружать все собранные им сборки - рекурсивно. Как это можно достичь? В общем, они должны быть доступны либо в папке Bin, либо в GAC:
- Вы можете попросить разработчиков найти папку установки и добавить ссылки на все сборки N, которые вы там разместите. Это гарантирует, что они будут скопированы в папку Bin, чтобы они были доступны во время выполнения.
- Вы можете установить шаблон проекта VS.NET , уже содержащий эти 6 ссылок. Немного сложный, так как перед установкой вы должны ввести фактический путь к вашим сборкам в этот шаблон. Это может быть сделано только установщиком, поскольку этот путь зависит от пути установки.
- Вы можете попросить разработчиков создать специальный шаг пост-сборки в файле .csproj/.vbproj, копируя необходимые зависимости в папку Bin. Те же недостатки.
- Наконец, вы можете установить все свои сборки в GAC. В этом случае разработчики должны добавить ссылку только в MyProduct.Facade.dll из своего проекта. Все остальное будет доступно во время выполнения.
Примечание. Последняя опция не позволяет делать то же самое при отправке проекта на производственные ПК. Вы можете либо отправить все сборки в папку Bin, либо установить их в GAC - все зависит от вашего желания.
Таким образом, описанное решение показывает преимущество включения сторонних сборок в GAC во время разработки. Это не связано с производством.
Как вы можете обнаружить, установка в GAC в основном предназначена для решения проблемы размещения необходимых сборок (зависимостей). Если сборка установлена в GAC, вы можете считать, что она существует "рядом" с любым приложением. Это похоже на добавление пути к .exe в вашу переменную PATH, но "управляемым способом". - конечно, это довольно упрощенное описание;)
Ответ 6
Я думаю, что одним из самых больших преимуществ использования GAC является то, что вы можете иметь несколько версий одной и той же сборки, зарегистрированной и доступной для ваших приложений. Лично мне не нравится, как он ограничивает перемещение с машины на машину (мне не нравится говорить, проверяйте источник на новом VPC и выполняйте кучу шагов, чтобы запустить его, потому что я должен регистрировать материал в ПКК)
Ответ 7
GAC работает с полным доверием и может использоваться приложениями вне вашего веб-приложения. Например, задания таймера в Sharepoint HAVE должны находиться в GAC, потому что служба sptimer представляет собой отдельный процесс.
Часть "Полное доверие" также является источником проблем безопасности. Конечно, вы можете работать с защитой доступа кодов, но я не вижу слишком много сборок с помощью CAS:( Папка /bin может быть заблокирована до Medium, которая обычно нормально.
У Дэниела Ларсона есть пост в CAS, который детализирует различия немного больше.
Ответ 8
Всю свою жизнь у меня было, возможно, одно приложение, в котором мне нужно было собрать сборку в GAC, просто потому, что эти сборки были частью структуры, которую использовали бы в ряде приложений, и было бы правильно разместить их в ПКК.