Решения для Visual Studio с большими количествами проектов
Я вижу разработчиков, часто разрабатывающих против решения, содержащего все проекты (27) в системе. Это повышает проблемы продолжительности сборки (5 минут), производительность Visual Studio (таких как задержка intellisense), плюс она не вынуждает разработчика думать о зависимостях проекта (пока они не получают проблему циклической ссылки).
Действительно ли это - хорошая идея сломать решение как это в меньшие решения, которые являются компилируемым и тестируемым независимым политиком "родительского" решения? Есть ли какие-либо потенциальные ловушки с этим подходом?
6 ответов
Позвольте мне еще раз сформулировать ваши вопросы:
Это хорошая идея разбить подобное решение на более мелкие решения
В статье MSDN, на которую вы ссылаетесь , довольно четкое заявление:
Важно Если у вас нет очень веских причин для использования модели с несколькими решениями, вам следует избегать этого и принять либо модель одного решения, либо в более крупных системах модель отдельного решения с разделами. С ними проще работать, и они предлагают ряд существенных преимуществ по сравнению с моделью с несколькими решениями, которые обсуждаются в следующих разделах.
Более того, в статье рекомендуется всегда иметь один «главный» файл решения в процессе сборки.
Есть ли в этом подходе какие-либо потенциальные ловушки?
Вам придется иметь дело со следующими проблемами (что на самом деле может быть довольно сложно решить, тот же источник, что и в приведенной выше цитате):
Модель с несколькими решениями страдает от следующие недостатки:
- Вы вынуждены использовать ссылки на файлы, когда вам нужно ссылаться сборка, созданная проектом в отдельное решение. Эти (в отличие от ссылки на проекты) не автоматически настроить сборку зависимости. Это означает, что вы должны решить вопрос сборки решения заказ в скрипте сборки системы. Хотя этим можно управлять, он добавляет дополнительная сложность в процессе сборки.
- Вы также вынуждены ссылаться на конкретную сборку конфигурации DLL (например, Release или Debug версия). Ссылки на проекты автоматически управлять этим и ссылка на текущий активный конфигурация в Visual Studio.СЕТЬ.
- Когда вы работаете с отдельными решениями, вы можете получить последний код. (возможно, в других проектах) разработан другими членами команды для выполнения локальных интеграционное тестирование. Вы можете подтвердить что ничего не ломается, пока ты не проверишь ваш код обратно в VSS готов к следующая сборка системы. В многофункциональном решении системе это сделать намного сложнее, потому что вы можете протестировать свое решение против других решений только с помощью результаты предыдущей системы строить.
У нас есть решение ~ 250 проектов.
Это нормально, после установки патча для Visual Studio 2005 для быстрой работы с очень большими решениями [TODO add link].
У нас также есть более мелкие решения для команд с выбором их любимых проектов, но каждый добавленный проект также должен быть добавлен к основному решению, и многие люди предпочитают работать с ним.
Мы перепрограммировали ярлык F7 (сборка) для сборки запускаемого проекта, а не всего решения. Так-то лучше.
Папки решений, похоже, решают проблему поиска вещей.
Зависимости добавляются только к проектам верхнего уровня (EXE и DLL), потому что, когда у вас есть статические библиотеки, если A является зависимостью от B, а B является зависимостью от C, A часто может не зависеть от C (в чтобы заставить вещи компилироваться и работать правильно), и, таким образом, циркулярные зависимости подходят для компилятора (хотя и очень вредны для психического здоровья).
Я поддерживаю использование меньшего количества библиотек, вплоть до наличия одной библиотеки с именем «библиотека». Я не вижу значительных преимуществ оптимизации объема памяти процесса за счет использования «только того, что ему нужно», и компоновщик должен делать это в любом случае на уровне объектного файла.
Производительность Intellisense должна быть немного лучше в VS2010 по сравнению с VS2008. Кроме того, зачем вам все время перестраивать все решение? Это произойдет только в том случае, если вы измените что-то рядом с корнем дерева зависимостей, иначе вы просто создадите проект, над которым сейчас работаете.
Я всегда считал полезным иметь все в одном решении, потому что я мог легко перемещаться по всей базе кода.
Единственный раз, когда я действительно вижу необходимость во множестве решений, - это функциональная изоляция. Необходимые библиотеки для службы Windows могут отличаться от библиотек для веб-сайта. Каждое решение должно быть оптимизировано для создания единого исполняемого файла или веб-сайта, IMO. Это улучшает разделение задач и позволяет легко перестроить функциональную часть приложения, не создавая вместе с ней все остальное.
Visual Studio 2010 Ultimate имеет несколько инструментов, которые помогут вам лучше понять и управлять зависимостями в существующем коде:
- Графы зависимостей и Architecture Explorer
- Диаграммы последовательностей
- Диаграммы слоев и валидация
Для получения дополнительной информации смотрите Exploring Existing Code. Пакет Visualization and Modeling Feature Pack обеспечивает поддержку графов зависимостей для кода на C++ и C.
У этого, безусловно, есть свои преимущества и недостатки. В любом случае разбиение решения на несколько проектов поможет вам легко найти то, что вы ищете, т.е. если вы ищете что-то об отчетности, вы переходите к проекту отчетности. это также позволяет большим командам разделять работу таким образом, чтобы никто не делал что-либо, чтобы сломать чужой код ...
Это поднимает проблемы продолжительности сборки
, вы можете избежать этого, создавая только те проекты, которые вы изменили и пусть CI-сервер сделает всю сборку