Каковы преимущества и недостатки использования GAC?

Question

И, кроме того, есть ли случаи, когда нужно использовать глобальный кэш сборок или когда его нельзя использовать?

Answer 1

• Загрузка сборок из GAC означает меньшую нагрузку и безопасность, так что ваше приложение всегда будет загружать правильную версию библиотеки .NET
• Вы не должны использовать ngen сборки, находящиеся вне GAC, потому что прирост производительности практически не будет, во многих случаях даже потеря производительности.
• Вы уже используете GAC, потому что все стандартные сборки .NET фактически находятся в GAC и ngened (во время установки).
• Использование GAC для ваших собственных библиотек усложняет развертывание, я бы попытался избежать этого любой ценой.
• Ваши пользователи должны быть зарегистрированы как администраторы во время установки, если вы хотите поместить что-то в GAC, что является большой проблемой для многих типов приложений.

Итак, чтобы подвести итог, начните с простого, и если позже вы увидите значительное увеличение производительности, если вы поместите свои сборки в GAC и NGEN их, сделайте это, иначе не беспокойтесь. GAC больше подходит для фреймворков, где ожидается, что библиотека будет распределена между большим количеством приложений, в 99% случаев она вам не нужна.

Answer 2

Преимущество:

• Только одно место для обновления ваших сборок
• Вы используете немного меньше места на жестком диске

Недостаток:

• Если вам нужно обновить только один веб-сайт, вы не сможете. Вы можете закончить с другими веб-серверами в сломанном

Рекомендация: оставьте GAC для MS и друзей. Гигабайт сейчас очень дешев.

Answer 3

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

Например, допустим, у вас есть приложение ASP.NET с частичным доверием, которому необходимо выполнить задачу, для которой потребуются повышенные привилегии, т. Е. Полное доверие . Решение состоит в том, чтобы поместить код, который требует повышенных привилегий, в отдельную сборку. Сборка помечается атрибутом AllowPartiallyTrustedCallers, а класс, содержащий привилегированную логику, помечается атрибутом PermissionSet, что-то вроде этого:

[PermissionSet(SecurityAction.Assert, Unrestricted=true)]

Нашей сборке будет присвоено строгое имя (подписано), а затем она будет развернута в GAC.

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

Answer 4

Если вы отправляете многократно используемую библиотеку, состоящую из нескольких сборок, но только немногие из них образуют фасад, вы можете рассмотреть возможность установки сборок в 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, но «управляемым способом». - конечно, это довольно упрощенное описание;)

Answer 5

GAC работает с полным доверием и может использоваться приложениями вне вашего веб-приложения. Например, задания таймера в Sharepoint ДОЛЖНЫ быть в GAC, поскольку служба sptimer является отдельным процессом.

Часть «Полное доверие» также является возможным источником проблем безопасности. Конечно, вы можете работать с Code Access Security, но я не вижу слишком много сборок, использующих CAS, к сожалению :( Папка / bin может быть заблокирована на Medium, что обычно нормально.

У Даниэля Ларсона также есть пост на CAS , в котором подробно описываются различия.

Answer 6

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

Answer 7

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