Когда я должен развернуть свои сборки в GAC?

Ответ 1

Вопрос: Когда я должен развернуть свои сборки в GAC?

Ответ: Никогда

Фактический, честный, реальный ответ: Вряд ли когда-либо

Обсуждение

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

Примером последнего является: предположим, что у вас есть 2 независимых приложения, независимо разработанные и независимо используемые. Тем не менее, существует вероятность того, что они будут взаимодействовать друг с другом. Они обменяются... чем-то... поверх .NET. Удаляются на локальном компьютере. Если у вас есть одна сборка в GAC, эти приложения гарантируют, что взаимодействие будет работать. Если, однако, каждый из них имеет отдельную версию сборки, они могут не иметь возможности обмениваться объектами. Это такое редкое явление, что вам, вероятно, это не нужно. Если вы не уверены, то вам это не нужно.

Базовый сценарий GAC - это библиотека базового класса .NET. Эти сборки поставляются Microsoft. Они авторитетны. Они основополагающие. и подписал. Они редко меняются. Все приложения должны использовать те же копии этих DLL. Поэтому они принадлежат к ПКК.

Напротив, ваши DLL файлы приложений не принадлежат Microsoft, они не основаны и, вероятно, не подписаны. Они меняются чаще, и есть только несколько приложений (возможно, только один!), Которые используют каждую DLL. Нет GAC.

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

Ваш пример log4net, на мой взгляд, недостаточно, чтобы оправдать установку сборки в GAC. Представьте себе сценарий, когда одно из приложений получает обновление, а в качестве части обновления используется новая версия log4net. Что теперь? Должна ли новая сборка log4net быть помещена в GAC? Возможно нет.

Вся идея совместного использования DLL-приложений в приложениях основывалась на предпосылке, что памяти и дискового хранилища недостаточно. Когда-то это было правдой. Это еще не так. Если вы сомневаетесь, не используйте GAC.

Ответ 2

log4net.dll имеет размер 95 КБ. даже если вы разворачиваете его 100 раз, это не имело бы значения с сегодняшними жесткими дисками. я стараюсь избегать GAC, где это возможно, по нескольким причинам:

• это упрощает развертывание, вы должны сообщить установщику, что добавить в GAC. Мне нравится создавать простые xcopy-установки (скопируйте каталог для установки, удалите его для удаления). потому что это просто - но это не работает так хорошо, как только вы должны поместить вещи в GAC.
• вам нужно подписать свои сборки. только чтобы получить их в GAC....
• как только разработчик ссылается на что-то из GAC в своем проекте visual studio, ссылка будет потеряна, когда другой разработчик откроет решение на своем ПК. он сначала должен получить необходимые сборки в GAC, прежде чем он сможет успешно открыть и скомпилировать решение. что настоящий PITA. я хочу иметь возможность проверять, компилировать и запускать без ошибок.

Ответ 3

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

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

Я видел, как люди евангелизировали чудо общего кода. Они говорят, что такие вещи, как "ах, мы будем улучшать 20 приложений одновременно с этим изменением кода". Проблема в том, что вы можете также уничтожить 20 приложений одновременно, если вы ошибетесь. Я видел, как люди говорят: "Я только что запустил сайт X. Можете ли вы проверить сайты A-W, чтобы убедиться, что они все еще работают?".

Частные сборки могут быть больно, но проблемы, с которыми вы можете столкнуться, ограничены конкретным приложением, с которым они развернуты. Если вы не на 100% уверены, что сборка нестабильная и зрелая, не помещайте ее в GAC.

Поверьте мне, вы лучше спать.

Ответ 4

То, что вы описываете, является достаточно приличной ситуацией для сборки сборки в GAC. Честно говоря, я бы избегал этого. С GAC вам нужно беспокоиться о сильных именованиях и доверенных собраниях и конкретном управлении версиями. Если у вас нет явной причины для этого. Так же просто развернуть dll несколько раз для каждого проекта.

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

Единственный раз, когда я когда-либо находил его полезным, было, когда мне приходилось создавать SharePoint Services WSS 2.0. Я натолкнулся на время, когда обновление раздела конфигурации, чтобы разрешить доверие было громоздким (из-за корпоративной политики) и помещением его в GAC, чтобы полностью доверять ему не было. Это был очень редкий случай.