Вопрос, который я хотел бы задать вашим коллегам, звучит так:

Хорошо, очень маловероятно, что мы потеряем все наши двоичные файлы одновременно. Но скажите мне, в чем польза такого подхода?

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

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

Хм, я думаю, что с точки зрения вопроса OP, о проектах строительство с нуля, это плохая практика из-за:

1. Невозможность сборки из исходного кода / с нуля - что, если я буду поддерживать несколько версий кода. Между каждой версией было внесено несколько изменений в каждую из библиотек. Единственный способ, которым я могу поддерживать эти параллельные версии, - это теперь хранить скомпилированные двоичные файлы в моем элементе управления версиями. Это также означает, что сравнивать каждую версию библиотеки намного сложнее. (Мне нужно выяснить, какая версия используется, а затем посмотреть фактический исходный код библиотеки, а не просто прямую разницу в самом источнике.
2. Возможно, сложнее распространять патчи клиентам, у которых есть инкрементно патченные версии. Где и что патчить?

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

Я часто это замечал на сборках утилит. Должен быть антипаттерн.

Круговые зависимости плохи, потому что:

• проект A ссылается на проект B
• при изменении проекта B проект A необходимо перестроить
• теперь, если проект B также ссылается на проект A
• затем, когда один из них меняется, другой нужно перестраивать
• что приводит к необходимости восстановления другого
• что приводит к необходимости восстановления другого
• и т.п.

это потенциально бесконечный цикл в процессе сборки

Это один из симптомов сверхмодуляризации.

Однажды я работал в компании, в которой было около двадцати разработчиков и более шестидесяти различных активных проектов в репозитории SVN. Каждый проект имел свой собственный сценарий сборки и создавал файл JAR, который зависел как минимум от полдюжины или около того других проектов. Управление всеми этими зависимостями было настолько сложным, что мы потратили кучу времени, пытаясь (я мог бы добавить, безуспешно) настроить проекты maven на автоматическое получение всех правильных библиотек (и правильных версий) для всех этих небольших микропроектов.

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

Блин.

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

Конечно, модульность - это вообще хорошо.

Но, как и все хорошее, его можно довести до смехотворных крайностей.

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

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

Visual Studio 2008 явно запрещает циклические ссылки между проектами (не двоичными файлами) в решениях. Как вы заявили, это не относится к двоичным файлам. Я считаю, что это потому, что VS2008 ожидает, что двоичные ссылки управляются независимо, и ожидает, что вы создаете эти проекты независимо. Вообще говоря, это означает, что все двоичные ссылки следует рассматривать как сторонние компоненты, которые представляют собой отдельные односторонние отношения (между вашим кодом и двоичным кодом).

Кроме того, MSBuild позволяет использовать файл SLN для сборки всего, если все ваши проекты используют VB или C#. Это позволяет создать файл uber-решения, который идеально подходит для автоматизированного процесса сборки. Загвоздка в том, что для того, чтобы такой главный файл решения работал, все проекты в SLN должны использовать ссылки на проекты. Следовательно, чтобы воспользоваться этим преимуществом, Microsoft по определению ожидает, что вы не используете циклические ссылки, поскольку они явно запрещены IDE Visual Studio (для ссылок на проекты).

Скотт Хансельман ссылается на файл uber-решения в следующем сообщении:
Взлом: параллельные сборки MSBuild из среды Visual Studio IDE
. http://www.hanselman.com/blog/CategoryView.aspx?category=MSBuild

Если вам трудно убедить своих «прагматичных» коллег в том, что это плохая практика, предложите прагматичное решение: удалите эти циклические ссылки, и время сборки сократится, так как можно избежать множества ненужных перестроек.