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

Question

Я часто вижу разработчиков, разрабатывающих решения, содержащие все проекты (27) в системе.Это поднимает проблемы длительности сборки (5 минут), производительности Visual Studio (например, задержка intellisense), а также не заставляет разработчиков задумываться о зависимостях проекта (пока они не получат проблему с циклической ссылкой).

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

Answer 1

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

Это хорошая идея, разбить подобное решение на более мелкие решения

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

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

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

Есть ли потенциальные подводные камни при таком подходе?

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

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

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

Answer 2

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

• Графики зависимостей и Architecture Explorer
• Диаграммы последовательности
• Диаграммы слоев и валидация

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

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

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

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

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

Answer 7

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

Это поднимает проблемы длительности сборки

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