Ответ 1
Установив буквально сотни проектов на протяжении многих лет, специализируясь на управлении конфигурацией программного обеспечения и выпуске, я бы рекомендовал сначала сосредоточиться на том, как вы хотите создавать/выпускать свои проекты.
Если вы используете только IDE для сборки (компиляции и упаковки) ваших проектов, вы можете просто следовать правилам, типичным для этой среды разработки, а также к любым "лучшим практикам", которые вы можете найти.
Однако я бы настоятельно рекомендовал, чтобы вы не строили только с помощью IDE или даже вообще. Вместо этого создайте автоматическую сборку/выпуск script, используя один или несколько из многих замечательных инструментов с открытым исходным кодом. Поскольку вы ориентируетесь на Windows, я рекомендую начать с просмотра Ant, Ivy и соответствующего xUnit (jUnit для Java, nUnit для .NET и т.д.) Для тестирования.
Как только вы начнете с этого пути, вы найдете много советов относительно структуры проекта, разработки сценариев сборки, тестирования и т.д. Вместо того, чтобы подавить вас подробными советами сейчас, я просто оставлю вас с этим предложением - вы будете легко найти ответы на свой вопрос там, а также найти еще много вопросов, которые стоит исследовать.
Наслаждайтесь!
Основываясь на комментариях, кажется, что необходимы некоторые детали.
Особая рекомендация, которую я хотел бы сделать, заключается в том, что вы разделяете свою кодовую базу на отдельные подпроекты, каждая из которых производит единый продукт. Основное приложение (.EXE) должно быть одним, любые поддерживающие двоичные файлы будут отдельными проектами, установщик будет отдельным проектом и т.д.
Каждый проект создает единый основной результат:.EXE,.DLL,.HLP и т.д. Этот поставляемый "опубликован" в один, общий, локальный, выходной каталог.
Создайте дерево каталогов, в котором подпроекты являются одноранговыми узлами (без глубины или иерархии, потому что это не помогает) и НЕ позволяют проектам "достигать" друг друга в поддереве - каждый проект должен быть полностью независимым, причем зависимости ТОЛЬКО на основные результаты других подпроектов, на которые ссылаются в общем каталоге вывода.
НЕ создавайте иерархию скриптов сборки, которые вызывают друг друга, я сделал и обнаружил, что он не добавляет значения, а экспоненциально увеличивает затраты на обслуживание. Вместо этого сделайте непрерывную интеграцию script, которая вызывает вашу автономную сборку script, но сначала выполняет чистую проверку во временную директорию.
НЕ выполняйте какие-либо конечные результаты или зависимости в исходном элементе управления - не вывод сборки, а не те библиотеки, которые вы используете, и т.д. Используйте Ivy для двоичного репозитория Maven, который вы развертываете отдельно от исходного элемента управления, и публикуйте свои собственные его результаты для обмена в вашей организации.
О, и не используйте Maven - он слишком сложный, запутывает процесс сборки и поэтому не экономичен для настройки.
Я двигаюсь к SCons, BuildBot, Ant, Ivy, nAnt и т.д. на основе моей целевой платформы.
Я составлял документ по этой теме, который, как я вижу, может иметь аудиторию.
EDIT: см. мой подробный ответ на Как организовать репозиторий управления версиями?