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

Question

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

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

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

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

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

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

Answer 1

Общие рекомендации по РС

1. НЕТ
2. НЕТ
3. НЕТ

GAC на самом деле является репозиторием для Microsoft common .СЕТЕВЫЕ библиотеки.Да, они тоже позволяют разработчикам использовать его, но, как правило, если вам не нужен GAC, не используйте его.делайте все просто и локально, если это не повредит.

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

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

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

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

Answer 2

Полезные кейсы для GAC:

• COM-вызываемый код - т. е.вам нужен какой-то не-.СЕТЕВОЙ код, чтобы иметь возможность обращаться к вам, не возясь с библиотеками dll и т. Д
• Обслуживаемые Компоненты (COM+)
• Если вы пишете код, который настолько распространен, что на самом деле имеет смысл использовать GAC - в первую очередь .Компоненты NET framework и т. Д
• Если вы хотите использовать NGEN для предварительной настройки кода

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

Answer 3

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

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

Answer 4

Если вы отправляете повторно используемую библиотеку, состоящую из нескольких сборок, но лишь немногие из них образуют фасад, вы можете рассмотреть возможность установки сборок в GAC, если пакет установлен на ПК разработчика.

Представьте, вы отправляете 6 сборок, и только одна из этих 6 сборок содержит фасад, т.е.остальные 5 используются только самим фасадом.Вы отправляете:

• Мой продукт.Facade.dll - это единственный компонент, предназначенный для использования разработчиками
• MyProduct.Core.dll - используется MyProduct.Facade.dll , но не предназначен для использования разработчиками
• Мой продукт.Component1.dll - то же самое
• Мой продукт.Component2.dll - то же самое
• ThirdParty.Lib1.dll - сторонняя библиотека, используемая MyProduct.Component1.dll
• ThirdParty.Lib2.dll - то же самое
• и т.д.

Разработчики, использующие ваш проект, хотели бы ссылаться только Мой продукт.Facade.dll в своих собственных проектах.Но когда их проект запускается, он должен иметь возможность загружать все сборки, на которые он ссылается - рекурсивно.Как этого можно достичь?В общем, они должны быть доступны либо в папке Bin, либо в GAC:

• Вы можете попросить разработчиков найти вашу папку установки и добавить ссылки на все N сборки, которые вы туда помещаете.Это гарантирует, что они будут скопированы в папку Bin, чтобы быть доступными во время выполнения.
• Вы можете установить VS.NET шаблон проекта уже содержащий эти 6 ссылок.Немного сложно, так как вы должны впрыснуть фактический путь к вашим сборкам в этом шаблоне до того , как его установка.Это может быть сделано только установщиком, так как этот путь зависит от пути установки.
• Вы можете попросить разработчиков создайте специальный этап после сборки в файле .csproj / .vbproj копирование необходимых зависимостей в папку Bin.Те же недостатки.
• Наконец, вы можете установите все ваши сборки в GAC.В этом случае разработчики должны добавить ссылку только на MyProduct.Facade.dll из своего проекта.Все остальное в любом случае будет доступно во время выполнения.

Примечание:последний вариант не заставляет вас делать то же самое при отправке проекта на рабочие компьютеры.Вы можете либо отправить все сборки в папку Bin, либо установить их в GAC - все зависит от вашего желания.

Таким образом, описанное решение показывает преимущество помещения сторонних сборок в GAC во время разработки.Это не имеет отношения к производству.

Как вы можете обнаружить, установка в GAC в основном предназначена для решения проблемы расположения требуемых сборок (зависимостей).Если сборка установлена в GAC, вы можете считать, что она существует "рядом" с любым приложением.Это все равно что добавить path к .exe в вашу переменную PATH, но "управляемым способом". - конечно, это довольно упрощенное описание ;)

Answer 5

Вот ссылка от Криса Селлса под названием "Избегайте GAC".

https://sellsbrothers.com/12503

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

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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