Я думаю, что никаких специальных решений не требуется. В нашем проекте (несколько приложений, которые разделяют большие области кода) мы используем следующий подход:
- Разделение исходного кода на папки.
- Создание пакетов для логических единиц общего кода.
- Поддержка монолита (без использования пакетов) и разделенных сборок.
- Монолитные сборки используются для кодирования и отладки. Каждое приложение имеет свой собственный выходной каталог Unit, поэтому все они создаются независимо.
- Ограничения зависимостей применяются путями поиска проектов.
- Раздельные сборки создаются автоматически (мы используем сервер CruiseControl и проект MSBuild). Автоматическая сборка очищает все временные папки перед сборкой, поэтому между последовательными сборками нет никаких зависимостей.
В нашем случае мы не могли контролировать список импортируемых файлов. Однако мы можем контролировать список импортируемых пакетов в разделенных сборках. Меньшие пакеты означают лучшую гранулярность. Если кто-то добавляет зависимость к устройству, расположенному в папке, которая недоступна в пути поиска, и пакет, содержащий это устройство, отсутствует в списке использований, сборка с разделением завершается неудачно. Таким образом, для добавления зависимости требуется явное действие (изменение сценария MSBuild, который генерирует файлы CFG для раздельной сборки).
P.S. Мы используем пакеты не для контроля зависимостей, а из-за проблем с версиями Windows, отличными от NT, при запуске больших приложений. Таким образом, контроль зависимостей является побочным эффектом. Раздельные сборки рассматриваются как «релизные», а монолитные - как «отладочные». Монолитные приложения используются только для кодирования и отладки. Разработчики работают с монолитными приложениями и вносят свои собственные изменения в конфигурации проекта, такие как присоединение отладочной информации VCL, ошибки проверки включения и выключения диапазона, оптимизация и т. Д. Однако после фиксации в SVN CC пытается выполнить сборку с разделением. Он игнорирует файлы CFG из репозитория и воссоздает их, используя специальную задачу проекта MSBuild. Таким образом, мы можем быть уверены, что никаких проблем с зависимостями не было (и выполнять другие проверки).
Поскольку нам не нужны монолитные и разделенные сборки одновременно, у нас есть только один проект на приложение. Если вы хотите построить обе версии в сценарии MSBuild, вы можете просто добавить еще одну цель, заново создать CFG и указать еще один выходной каталог Unit. Естественно, если для разработчиков требуются обе версии, было бы удобнее иметь больше проектов.