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

Ответ 1

Общие рекомендации MS

• нет
• нет
• нет

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 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, но "управляемым способом". - конечно, это довольно упрощенное описание;)

Ответ 5

Здесь ссылка от Chris Sells называется "Избегайте GAC"

https://sellsbrothers.com/12503

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

• Фиксирование критических ошибок, не касаясь затронутых приложений (и не нарушая ничего!)

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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