Когда и когда - не устанавливать в GAC?

Question

Когда вы должны установить в GAC, а когда нет? (Я имею в виду, на самом деле, установку на компьютере клиента, когда он приобрел наш продукт (ы)).

1. У меня есть сборка, которая будет использоваться только с одним моим приложением (GAC или без GAC)?

2. У меня есть сборка, которую разделяют все мои приложения (GAC или no-GAC)?

3. Все мои приложения может использовать разные версии моей сборки (GAC или no-GAC)?

Это три сценария ... но я уверен, что есть и другие. Я не обязательно ищу ответ только на эти три вопроса.

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

Answer 1

Общие указания по MS

1. нет
2. нет
3. нет

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

• Я бы рассматривал GAC только из соображений производительности, например, если у вас есть какие-то огромные сборки, попробуйте поместить их в GAC и NGEN . Это должно значительно повысить производительность. Microsoft делает это для всех стандартных сборок .NET Framework во время установки (теперь вы знаете, почему эта установка занимает так много времени). Paint.NET также делает это (чтобы улучшить время запуска своего приложения). Однако большинство из нас не работают с огромными фреймворками или конкурентами Photoshop, поэтому большую часть времени выигрыш в производительности от сборки в GAC минимален. Не стоит отказываться от простого развертывания ксерокопий.

• Некоторые разработчики могут использовать GAC, чтобы пользователи с недостаточными правами не могли удалять или изменять свои сборки.

• Для других это может быть по причинам управления версиями, но здесь вы должны действительно пересмотреть. Я не собираюсь повторять то, что уже было сказано, Вы можете прочитать здесь, почему .

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

Answer 2

Полезные случаи для GAC:

• COM-вызываемый код - т.е. вы хотите, чтобы какой-то не-.NET-код мог иметь к вам доступ, не связываясь с DLL и т. Д.
• Обслуживаемые компоненты (COM +)
• Если вы пишете столь распространенный код, на самом деле имеет смысл использовать GAC - прежде всего компоненты платформы .NET и т. Д.
• Если вы хотите использовать NGEN для предварительного JIT кода

Кроме этого, я склонен избегать GAC как чума. Гораздо проще просто развернуть необходимые библиотеки с вашим приложением через robocopy и т. Д .; это обеспечивает простоту развертывания и .

Answer 3

Если вы устанавливаете веб-приложения asp.net , и вы являетесь владельцем и имеете полный контроль над машиной, то в некоторых случаях может иметь смысл размещать ваши сборки, которые вы планируете общий доступ к сайтам / веб-экземплярам в глобальном кэше сборок.

Вы можете значительно улучшить начальное время загрузки и использование памяти приложением на серверах, которые имеют многократные экземпляры одних и тех же приложений ASP.NET, если вы поместите сборки в 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»

https://sellsbrothers.com/12503

Объяснение довольно длинное, но вкратце два случая, которые он идентифицирует,

1. Исправление критических ошибок, не затрагивая затронутые приложения (и ничего не нарушая!)

2. Совместное использование типов во время выполнения между сборками, развернутыми отдельно

Примечание: есть очень длинная ветка обсуждения в конце сообщения Криса , очень хороший список комментариев.

Answer 6

Установка в GAC имеет смысл только в том случае, если множество веб-приложений на одном сервере будут использовать одни и те же библиотеки. Например, на сервере Sharepoint могут быть сотни веб-сайтов, которым всем необходимо использовать одну и ту же веб-часть, поэтому в этом случае имеет смысл развернуть скомпилированную веб-часть в GAC.

Answer 7

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

в случае A определенно не GAC

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

при параллельном выполнении в случае C позволяет запускать разные версии сборки, и вам не нужно добавлять что-либо, чтобы различать версии.

Используется только если вам действительно нужно