Visual Studio: одно решение или множество решений?

В настоящее время этот старый код представляет собой несколько проектов, каждый из которых имеет собственное решение. Каждый проект ссылается на другой проект, скомпилированный dll. для запуска основного проекта вам нужно пройти через 10 + отдельные сборки в правильном порядке.

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

Ответ 1

Вы правы, и я объясню это другому разработчику с точки зрения преимуществ

Самый простой аргумент для меня - создание 1 раз намного быстрее, чем создание 1 решения 10 раз. Загрузка каждого отдельного решения требует утомительного и трудоемкого времени. Visual Studio делает вашу жизнь лучше, загружая решения 10 раз, просто делает вашу жизнь хуже.

Кроме того, размещение всех проектов в одном решении означает, что вы получаете активную поддержку многих функций, таких как IntelliSense, рефакторинг, поиск всех ссылок и т.д. Имея живые ссылки на проекты, вы получаете лучший опыт , чем через DLL. Рефакторинг - это одна из функций, которая сильно ограничена в ней полезностью при просмотре DLL.

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

Ответ 2

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

Производительность. Да, здание может быть менее утомительной задачей, но перестроить кучу "основных" проектов, которые редко меняются, поскольку Джаред сказал, что вы можете смягчить это с помощью конфигураций сборки. Также Visual Studio имеет тенденцию быть ресурсоемкой, и проблема, по моему опыту, усугубляется по мере роста вашего решения. Если у вас есть основные части, которые меняются нечасто, то в чем польза от их загрузки все время?
Рефакторинг - это ИМО с двойным острием. Да, легче всего переименовывать, перемещать, заменять и т.д., Когда загружается весь код. Однако, поскольку это проще, вы также можете столкнуться с ситуациями, когда люди будут добавлять ссылки на проекты и перемещать объекты по границам проекта, когда с архитектурной точки зрения это неправильный подход. Поскольку VS упрощает работу, вам нужно следить за тем, чтобы люди слепо рефакторировали и нарушали архитектурные принципы.

P & P опубликовал некоторые рекомендации по этой теме: http://msdn.microsoft.com/en-us/library/bb668953.aspx

Он немного устарел и говорит о TFS конкретно, но некоторые из основных концепций по-прежнему ценны для рассмотрения.

Ответ 3

Сделайте это самостоятельно в локальной копии, а затем вы можете показать им, почему это лучше.