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

Question

Я хотел бы знать, какие именно сборки следует развернуть в GAC.

Случай 1 : если в моем решении несколько проектов используют log4net.dll, то следует ли его развертывать в GAC?

Случай 2 : Если у меня на компьютере развернуто несколько приложений, каждое из которых использует log4net.dll, является ли этой причиной достаточно для развертывания log4net.dll в GAC?

Answer 1

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

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

Фактический, честный, реальный ответ: Едва ли

Обсуждение

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

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

---

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

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

---

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

---

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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