Каков наилучший способ борьбы с общими DLL в C #?

Question

В моей команде есть сотни общих библиотек, многие из которых также ссылаются на другие библиотеки, которые сами ссылаются на другие библиотеки, и так далее. Мы начали использовать каталог «Shared» для всех dll, которые, по нашему мнению, достаточно универсальны для использования в других проектах, таких как база данных coms dll.

Проблема в том, что если одна из библиотек на всем пути вниз по дереву изменяется, то все, что на нее ссылается, необходимо перекомпилировать, чтобы избежать проблем с версиями (которые возникают во время выполнения).

Чтобы избежать этого, сейчас говорят о добавлении всех наших «общих» библиотек в одну большую сборку, и любой, кто создает новые приложения, просто ссылается на это и только на это.

Это, очевидно, будет становиться все больше и больше, и я не уверен, является ли это лучшим способом или нет. Есть мысли, пожалуйста?

Answer 1

Что мы делаем, так это относимся к поддержке общих DLL как к самому проекту, со своим собственным контролем версий и всем остальным. Затем, примерно два раза в год, мы делаем «публикацию» общих библиотек DLL для публики, с собственным номером версии и всем остальным. Пока вы всегда используете библиотеки DLL как «набор» (то есть все те, на которые вы ссылаетесь, относятся к одному выпуску), вы гарантированно не будете иметь никаких проблем с зависимостями.

Answer 2

вы можете сделать одно решение, включающее все подключенные проекты .
и когда вам нужно выпустить, просто создайте это решение

---

Update.
Как вы говорите, решение не может вместить столько DLL.
В другой руке вы можете сделать внешний MSBuild скрипт или с использованием CruiseControl.NET , которые могут выполнять такие сложные задачи.

Answer 3

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

Звучит так, как будто тебе действительно нужно разделить свои проблемы немного лучше. Если все эти библиотеки DLL ссылаются друг на друга, они, вероятно, слишком тесно связаны. Настоящая «общая» DLL должна быть в состоянии стоять самостоятельно или как часть пакета из трех или четырех, которые путешествуют как группа. Если ваши зависимости фактически мешают вам вносить изменения, значит, ваша стратегия связывания пошла ужасно неправильно.

Помещение всего в одну большую DLL, безусловно, не улучшит ничего. На самом деле, вероятно, наоборот. Как только вы соберете все в одну DLL, возникнет соблазн соединить все внутри нее еще теснее, что сделает невозможным дальнейшее разборку вещей.

Answer 4

Цитируя из книги GoF, «Программа для интерфейса, а не для реализации». Это может относиться здесь к некоторым вашим библиотекам. Вы уже знаете о том, насколько хрупким становится ваше развитие, когда вы тесно связаны. Теперь нужно решить, как дать вам передышку.

• Вы можете создать интерфейс. Это обеспечит контракт, который любое приложение может использовать, чтобы указать, что доступен минимальный набор функций.

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

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

Такие продукты, как редакторы разработки и веб-браузеры, используют этот подход, чтобы сделать возможным повторное использование кода. Спасибо. Добрый день.

Принципы проектирования из шаблонов проектирования

Plugin