Пересмотр установок GAC

Question

Я знаю это, но я не могу найти удовлетворительного ответа.

Должны ли сборки идти в GAC? Эти вопросы: когда и когда не нужно устанавливать в gac и Каковы преимущества и недостатки использования GAC , обращайтесь именно к этому, но к ответам очень "рекомендуется ..." или "вы должны только ...". Почему ???

Похоже, что многие блоги GAC, высказывающие отрицание, датируются 5-6 лет назад, когда звезда .Net начинала свой подъем. Мы все еще там сейчас? Конечно, DLL-ад ушел в прошлое, когда GAC поддерживает параллельную установку разных версий «одной и той же» сборки?

Позвольте мне прояснить мои проблемы. У нас есть растущий набор веб-приложений (5 к настоящему времени). По своей сути они являются расширениями стороннего приложения с помощью вызовов API и расширений базы данных. Следовательно, очевидно, что все эти приложения имеют много общего кода, и мы разрабатываем новый набор базовых общих библиотек для улучшения качества, удобства обслуживания и т. Д.

Конечно, я хочу, чтобы эта общая функция была установлена ​​один раз и предоставлена ​​для общего доступа. Кажется, что все аргументы об открытии кошмара обслуживания основаны на некой дисциплине. Если вы нарушите ABI, то увеличение AssemblyVersion будет достаточным, чтобы ваши существующие приложения работали.

Является ли GAC действительно ловушкой для ничего не подозревающих? Я наивный? Неужели я излишне резок, когда отклоняю аргументы, ссылающиеся на потерю установки «XCopy», как на ленивые звуки? Или это становится немного "религиозным", и я должен просто пойти с тем, что кажется правильным?

Спасибо, что помогли мне увидеть свет.

Dan

Answer 1

Лично я никогда не устанавливал какие-либо сборки непосредственно в GAC (кроме как чисто академическое упражнение). Ранее я слышал спор об использовании сборки из централизованного местоположения, доступ к которому осуществляется из нескольких приложений, и, хотя это кажется несколько привлекательным, лично оно не стоит моего времени. В наши дни компьютеры имеют 320 ГБ места на жестком диске ... моя ничтожная сборка 160 КБ не сможет в этом помешать, даже если она будет скопирована 5 раз. (Конечно, некоторые могут утверждать, что «проблема общего достояния» ... вы знаете: «если бы каждый разработчик так думал…», но я отвлекся). Основная причина, по которой я предпочитаю этого не делать, заключается в том, что одно конкретное приложение может полагаться на сборку одним способом, а другое - на другое. Находясь в идеальном мире, обновления этой сборки никогда не должны влиять на приложения, которые на нее полагаются, в действительности это часто бывает. Если я исправляю проблему со сборкой из-за проблем, связанных с конкретным приложением, я невольно влияю на другие приложения, которые зависят от этой конкретной сборки. С другой стороны, некоторые могут утверждать, что такая ситуация делает нас лучшими программистами и делает нашу сборку GAC-Shared более пуленепробиваемой. Это замечательно, но моя работа как программиста состоит не в том, чтобы сделать себя лучше программистом, а в том, чтобы писать программы, которые работают, и поэтому я стану лучшим программистом.

Так, каков мой голос? Хранить вдали от GAC. Пусть каждое приложение полагается на версию сборки, на которую он построен. Ошибка, обнаруженная в этой сборке одним приложением, может никогда не появиться в других приложениях, потому что они используют сборку по-разному, поэтому оставьте их, и вам не придется регрессировать 5 разных приложений каждый раз, когда ваша общая DLL исправлена ,

Answer 2

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

любые комментарии приветствуются.