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

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

22.08.2008 21:41:58
Когда я сам исследовал эту тему, я обнаружил, что [Демистификация глобального кэша сборок .NET] ( codeproject.com/KB/dotnet/demystifygac.aspx). Джеремия Талкар мне очень помог.
Espo 22.08.2008 21:47:30
На это уже есть достаточно ответов, но я не могу не подчеркнуть это: НИКОГДА не развертывать в GAC. Со временем это станет кошмаром развертывания.
Tigraine 17.12.2008 11:01:02
T.S. 5.04.2019 02:40:16
7 ОТВЕТОВ

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

3
22.08.2008 21:44:06

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

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

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

48
22.08.2008 22:22:08
@Sam: проверьте msdn.microsoft.com/en-us/magazine/cc163610.aspx , в частности, раздел «Сборки и GAC»
lubos hasko 12.04.2013 09:27:42

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

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

Недостаток:

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

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

21
22.08.2008 23:08:10

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

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

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

7
22.08.2008 21:50:58

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

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

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

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

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

18
12.11.2014 14:43:14

Если вы отправляете библиотеку многократного использования, состоящую из нескольких сборок, но лишь немногие из них образуют фасад, вы можете рассмотреть возможность установки сборок в 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
21.06.2009 16:48:58
Это мило. Reeeaaaal хорошо. Мы используем сторонний компилятор COBOL .NET, который компилирует .dll, затем вызывает сторонний .dll, который мы пытаемся вызвать из VB6, добавляя только ссылку, которую мы создаем, а не стороннюю. Если бы я не читал это, я бы никогда не подумал об этом.
interesting-name-here 21.12.2016 14:48:11