Целостность проекта во многих приложениях

Question

Наша кодовая база состоит из двух приложений ASP.NET MVC, нескольких приложений WinForm и ассортимента консольных приложений и служб WCF.Все они основаны на одном и том же наборе библиотек классов доменов, уровня доступа к данным (управляемый NHibernate) и некоторых классов инфраструктуры (общие методы расширения, двоичные файлы сторонних производителей и абстрактная бизнес-логика).

Для обеспечения целостности ссылокмежду приложениями у нас есть решение под названием Builder.Builder содержит каждый отдельный проект и перекомпилирует все библиотеки DLL в локальной рабочей области.До сих пор это работало хорошо, но становится неуправляемым, его сборка занимает все больше и больше времени.

Мы стремимся разделить код на более конкретные сборки, сохраняя при этом целостность ссылок.Если кто-то изменит наш класс домена, остальная часть команды должна, например, перестроить Domain.dll.Неправильно добавлять двоичные файлы в систему контроля версий, но мы должны убедиться, что все используют одну и ту же версию.

Кажется, это обычное дело, но я не нашел хороших статей, специально посвященных этой проблеме.Кто-нибудь знает лучшую практику, которую мы можем использовать для этого?Спасибо!

Answer 1

Изучите другие 6 основополагающих принципов . Эти другие принципы объясняют, как работать с этими независимо развертываемыми модулями.

Answer 2

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

Если ваша проблема заключается в том, что вам нужноубедитесь, что и проект X, и проект Y используют одну и ту же версию вашей общей библиотеки, тогда ссылка на двоичный файл (и сохранение его в системе управления версиями) - ваш лучший подход.К сожалению, время сборки - это не то, что действительно может быть решено путем изменения подходов.

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