Каковы преимущества и недостатки использования GAC? - PullRequest
51 голосов
/ 23 августа 2008

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

Ответы [ 7 ]

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

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

21 голосов
/ 23 августа 2008

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

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

Недостаток:

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

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

18 голосов
/ 23 августа 2008

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

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

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

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

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

7 голосов
/ 21 июня 2009

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

7 голосов
/ 23 августа 2008

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

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

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

6 голосов
/ 23 августа 2008

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

3 голосов
/ 23 августа 2008

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

...