Когда я должен развернуть свои блоки в GAC?
Я хотел бы знать практически, какие блоки должны я развертываться в GAC.
Случай 1: Если в моем Решении несколько проектов используют log4net.dll затем, это должно быть развернуто в GAC?
Случай 2: Если у меня есть несколько приложение, развернутое в машине каждое использование, log4net.dll - это причина достаточно для развертывания log4net.dll в GAC?
4 ответа
Вопрос: Когда мне следует развертывать свои сборки в 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.
То, что вы описываете, является достаточно приличной ситуацией, чтобы поместить сборку в GAC. По правде говоря, я бы этого избегал. С GAC вам нужно беспокоиться о строгом именовании и доверии сборкам, а также о конкретных версиях сборок. Если у вас нет явной причины в этом необходимость. Так же легко развернуть dll несколько раз для каждого проекта.
Я знаю, что это противоречит хранению нескольких копий одного и того же фрагмента кода и т. Д. И т. Д., Но мне всегда было проще просто избегать использования GAC. Когда я его использовал, GAC всегда доставлял неудобства, потому что вам нужно беспокоиться, есть ли у GAC все правильные сборки для проекта (потому что сборки могут ссылаться на другие сборки). Когда вы не используете GAC, намного проще спросить: «Есть ли сборки?» «Да, они в папке приложения»
. Единственный раз, когда я нашел это полезным, был, когда мне пришлось создавать SharePoint Services WSS 2.0. Я столкнулся со временем, когда обновление раздела конфигурации, чтобы разрешить доверие, было обременительным (из-за корпоративной политики), а размещение его в GAC для обеспечения полного доверия - нет. Это был очень-очень редкий случай.
log4net.dll имеет размер 95 КБ. даже если вы развернете его 100 раз, это не будет иметь большого значения с сегодняшними жесткими дисками. Я стараюсь избегать GAC везде, где это возможно, по нескольким причинам:
- это усложняет развертывание, вы должны сообщить установщику, что вставить в GAC. Мне нравится возможность создавать простые настройки xcopy (скопировать dir для установки, удалить его для удаления). потому что это просто - но это не работает так хорошо, как только вам нужно поместить вещи в GAC.
- Вы должны подписать свои собрания. только для того, чтобы получить их в GAC....
- Как только разработчик ссылается на что-то из GAC в своем проекте Visual Studio, ссылка будет потеряна, когда другой разработчик откроет решение на своем пк. Сначала ему нужно будет получить необходимые сборки в глобальном сборке, прежде чем он сможет успешно открыть и скомпилировать решение. это настоящий PITA. Я хочу иметь возможность проверять, компилировать и запускать без ошибок.
Единственный вид сборки, которую вы должны рассмотреть для включения в GAC, - это зрелая и стабильная сборка. В случае log4net, если вы довольны тем, что имеющаяся у вас версия является стабильной, зрелой и вряд ли вы измените эту версию в ближайшее время, не стесняйтесь помещать ее в GAC.
Не пытайтесь размещать в GAC библиотеки, которые могут измениться, особенно если вы разрабатываете их собственными силами, и все еще есть возможности для дальнейшего улучшения. Вместо этого разверните их как частные сборки.
Я видел, как люди проповедовали чудо общего кода. Они говорят что-то вроде «а, мы улучшим 20 приложений одновременно с этим изменением кода». Проблема в том, что вы также можете уничтожить 20 приложений одновременно, если ошибетесь. Я видел, как люди говорили: «Я только что запустил сайт X. Не могли бы вы проверить сайты A-W, чтобы убедиться, что они все еще работают?».
Частные сборки могут вызывать затруднения, но проблемы, с которыми вы можете столкнуться, ограничены конкретным приложением, для которого они развернуты. Если вы не на 100% уверены, что сборка нестабильна и нестабильна, не помещайте ее в GAC.
Поверь мне, ты будешь спать лучше.