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

Ответ 1

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

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

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

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

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

Существуют ли какие-либо потенциальные проблемы с этим подходом?

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

Разве это хорошая идея разбить такое решение на более мелкие решения, которые можно компилировать и тестировать независимо от решения "матери"? Существуют ли какие-либо потенциальные проблемы с этим подходом?

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

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

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

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

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