Почему я НЕ должен использовать GAC?

Question

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

Почему я НЕ должен использовать GAC?

Answer 1

Крис Селлс, вероятно, дает лучшую причину избегать GAC , где вы можете:

То, к чему это сводится, - то, что любое из общих мест для обновлений, будь то COM CLSID, windows \ system32 или GAC, опасны и их следует избегать. И именно поэтому предпочтительным сценарием развертывания .NET является «развертывание xcopy», то есть наличие вашей собственной частной копии каждой библиотеки DLL, которую вы тестируете и внедряете вместе с остальной частью вашего приложения.

"Ага!" ты говоришь. «GAC поддерживает несколько версий сборки! Когда foo.dll обновляется до v1.1, v1.0 располагается рядом с ним, чтобы ваше приложение не ломалось!» Конечно, это абсолютно верно. Но если это так, то зачем тебе это? Я имею в виду, если есть новая сборка, но ваше приложение ее не берет, какая разница?

«Ага, еще раз! Вы говорите.« Я могу поместить политику издателя в GAC вместе со своей сборкой, чтобы приложения автоматически обновлялись ! »Это тоже правда, но теперь, как и любой из старые стратегии машинной замены кода, вы взяли на себя огромную ответственность: убедитесь, что почти 0% приложений, известных вам или нет, не сломались. Это огромная ответственность и один на каждую новую версию .NET Framework требуется MS сотни человеко-лет. И даже после сотен человеко-лет тестирования мы не всегда понимаем это правильно. Если это ответственность за тестирование, то вы желая жить с тобой, я восхищаюсь тобой. Лично у меня нет моральной силы, чтобы нести это бремя.

Answer 2

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

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

Я всегда чувствовал, что это гораздо полезнее для тех, кто создает SDK / API, где различные версии их SDK могут загружаться несколькими приложениями и жить в гармонии. Поэтому, если вы находитесь в этой лодке, тогда GAC может иметь смысл.

В некоторых случаях требуется GAC (я думаю, что компоненты .NET COM + должны быть в GAC в некоторых случаях), но я думаю, что это небольшой процент случаев.

Answer 3

Если вы хотите менее навязчивое развертывание вашего приложения. Установив только в каталог приложения, вы можете легко скопировать развертывание и очистку.

Answer 4

Какая польза от GAC?

i) Вы можете хранить несколько версий одной и той же сборки на машине и выполнять их одновременно. ii) Хранить одни и те же сборки в нескольких местах на машине, используя дополнительно ненужное хранилище. Хранение их в одном месте снижает эту стоимость. iii) Обслуживание сборок на машине упрощается, поскольку вам нужно обновить только одно местоположение (GAC), а не искать несколько экземпляров сборки, хранящихся на машине.

Answer 5

Я спросил что-то похожее ( Нужно ли мне когда-либо использовать глобальный кэш сборок (GAC)? )

Лучший ответ состоял в том, что «GAC полезен только в том случае, если вы регистрируете библиотеки, которые собираетесь использовать повторно».

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

Answer 6

Если у вас небольшое приложение, которое не требует больших ресурсов, я бы не хотел устанавливать файлы в GAC.

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

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

Answer 7

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