Как структурировать несколько перекрывающихся решений / проектов в .Net?

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

Я никогда не видел установки, которая переплетается, нет четкого порядка сборки, иногда проект в решении A, просто ссылка ссылается прямо из выходного каталога проекта, размещенного в решении B, иногда проект просто включается напрямую, даже если он находится Далеко в структуре папок.

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

Когда я столкнулся с ними, почему у них не было CI-сервера, они ответили, что трудно настроить код, организованный так, как он есть. (Я настраиваю это сейчас и проклинаю эту организацию кода)

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

Есть ли консенсус в отношении наилучшей практики при повторном использовании общих библиотек классов в нескольких решениях / артефактах развертывания,

• Как структурировать код в VCS
• Как облегчить совместное использование бизнес-логики между отдельными артефактами развертывания

Я никогда не был фанатом включения существующих проектов, которые относятся к другим решениям. Слишком много переменных, при которых редактирование этого проекта для одного решения полностью нарушает что-либо в другом решении. Тогда, решая эту проблему, вы в конечном итоге нарушаете первоначальное решение. Вспенить, промыть, повторить.

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

Я фактически организовал такие структуры TFS, как та, о которой вы упомянули, и, хотя она создает уникальные проблемы для CI, она имеет ряд различных преимуществ. Ясно одно: он поддерживает и поощряет правильную компонентизацию в отдельные проекты .NET и, таким образом, поддерживает хороший TDD, поощряя 100% охват тестированием. Сразу же я заметил несколько проблем, которые вы можете решить.

иногда проект в решении A просто ссылается на dll непосредственно из выходного каталога проекта, размещенного в решении B, иногда проект просто включается напрямую, даже если он находится в FAR в структуре папок.

Двоичные ссылки на выходные данные других каталогов не являются хорошим подходом и становятся плохим подходом, когда они также смешиваются со ссылками на проекты. Попробуйте сделать одно или другое, предпочтительно изменив ваши двоичные ссылки на ссылки на проекты для согласованности, по крайней мере. На этом этапе каждое Решение может представлять одно отдельное приложение или уровень приложения (например, SuperApp.sln, OtherAppServices.sln, OtherAppPresentationTier.sln).

Для создания ВСЕХ проектов я рекомендую также создать Master Solution. Мастер-решение будет иметь ссылки на проекты для всего и, по существу, существует только для того, чтобы иметь единственную команду сборки, которая обрабатывает все проекты в наборе приложений. Разработчики не должны использовать Master Solution для активной разработки или отладки. Это значительно упрощает сборку артефактов сборки.

Развертывание может быть выполнено с помощью простого пакетного сценария, powershell или Perl-скрипта. По сути, это создаст соответствующее решение или мастер-решение, а затем развернет все в соответствующих средах. Это может быть легко интегрировано в любой сервер CI, если все сделано правильно.

• Как облегчить совместное использование бизнес-логики между отдельными артефактами развертывания

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

При организации вашего кода в TFS становится легче достичь этого, поддерживая общие или общие проекты на более высоком уровне в дереве каталогов.