Решения Visual Studio с большим количеством проектов

Позвольте мне еще раз сформулировать ваши вопросы:

Хорошая идея - разбить подобное решение на более мелкие?

В статье MSDN, на которую вы ссылаетесь, делается довольно четкое заявление:

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

Более того, в статье рекомендуется, чтобы вы всегда использовали один «главный» файл решения в процессе сборки.

Есть ли в этом подходе возможные подводные камни?

Вам придется столкнуться со следующими проблемами (что на самом деле может быть довольно сложно сделать, из того же источника, что и в приведенной выше цитате):

Модель с несколькими решениями страдает следующими недостатками:

• Вы вынуждены использовать ссылки на файлы, когда вам нужно ссылаться на сборку, созданную проектом в отдельном решении. Они (в отличие от ссылок на проекты) не устанавливают автоматически зависимости сборки. Это означает, что вы должны решить проблему порядка сборки решения в сценарии сборки системы. Хотя этим можно управлять, это добавляет дополнительную сложность процессу сборки.
• Вы также вынуждены ссылаться на конкретную сборку конфигурации библиотеки DLL (например, версию Release или Debug). Ссылки на проекты автоматически управляют этим и ссылаются на текущую активную конфигурацию в Visual Studio .NET.
• Когда вы работаете с отдельными решениями, вы можете получить последний код (возможно, в других проектах), разработанный другими членами команды, для выполнения локального интеграционного тестирования. Вы можете убедиться, что ничего не сломалось, прежде чем снова вернете свой код в VSS, готовый к следующей сборке системы. В системе с несколькими решениями это сделать намного сложнее, потому что вы можете протестировать свое решение по сравнению с другими решениями, только используя результаты предыдущей сборки системы.

В Visual Studio 2010 Ultimate есть несколько инструментов, которые помогут вам лучше понять и управлять зависимостями в существующем коде:

• Графы зависимостей и обозреватель архитектуры
• Диаграммы последовательности
• Диаграммы слоев и проверка

Для получения дополнительной информации см. Изучение существующего кода. Пакет функций визуализации и моделирования обеспечивает поддержку графов зависимостей для C ++ и C код.

У нас есть решение ~ 250 проектов.

Это нормально, после установки патча для Visual Studio 2005 для быстрой работы с очень большими решениями [TODO add link].

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

Мы перепрограммировали ярлык F7 (сборка) для сборки запускаемого проекта, а не всего решения. Так-то лучше.

Папки решений, похоже, решают проблему поиска вещей.

Зависимости добавляются только к проектам верхнего уровня (EXE и DLL), потому что, когда у вас есть статические библиотеки, если A является зависимостью от B, а B является зависимостью от C, A часто может не быть зависимостью от C (чтобы сделать вещи компилируются и работают правильно), и таким образом круговые зависимости подходят для компилятора (хотя и очень вредны для психического здоровья).

Я поддерживаю использование меньшего количества библиотек, даже если есть одна библиотека с именем «библиотека». Я не вижу значительного преимущества оптимизации объема памяти процесса за счет предоставления «только того, что ему нужно», и компоновщик должен делать это в любом случае на уровне объектного файла.

Единственный раз, когда я действительно вижу необходимость в нескольких решениях, - это функциональная изоляция. Необходимые библиотеки для службы Windows могут отличаться от библиотек для веб-сайта. Каждое решение должно быть оптимизировано для создания единого исполняемого файла или веб-сайта, IMO. Это улучшает разделение задач и упрощает перестройку функциональной части приложения без создания всего остального вместе с ней.

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

Это вызывает проблемы с продолжительностью сборки.

вы можете избежать этого, создавая только те проекты, которые вы изменили, и позволяя серверу CI выполнять всю сборку

Производительность Intellisense должна быть немного лучше в VS2010 по сравнению с VS2008. Кроме того, зачем вам все время перестраивать все решение? Это произойдет только в том случае, если вы измените что-то около корня дерева зависимостей, иначе вы просто создадите проект, над которым сейчас работаете.

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

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

Да, это хорошая идея, потому что:

• Вы же не хотите, чтобы VS тормозил решение с десятками проектов VS.
• Может быть интересно сосредоточиться только на части кода, это усиливает понятие локальности кода, что хорошо.

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

• Разделение базы кода с помощью сборок .NET и проектов Visual Studio (8 страниц)
• Определение компонентов .NET с помощью пространств имен (7 страниц)

В первой белой книге также объясняется, что VS работает довольно медленно при работе с решением с десятками проектов, и демонстрируются приемы, как исправить эту медлительность.