Организация решения Visual Studio с помощью "Папки решений"

При настройке решения Visual Studio.NET со многими проектами вы находите полезным "Папки решений"? Каковы недостатки?

Моя первоначальная мысль заключалась в том, что использование Пакетов решений может быть полезно для логической организации подобных проектов в рамках решения. Однако я с удивлением узнал, что создание папки решений не создает соответствующую папку Windows. Из MSDN:

"Пакеты решений - это организационный инструмент в решении Проводник; соответствующие окна папки не создаются. Мы рекомендуем что вы организуете свои проекты на диска так же, как вы организуете их в решении".

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

ОТВЕТЫ

Ответ 1

Папки решений могут помочь в организации ваших проектов. И у них есть одно большое преимущество: если вы хотите создать несколько наборов проектов, вы можете их пометить и щелкнуть правой кнопкой мыши и выбрать "Сборка выбранных проектов". Если ваша организация папок решений подходит, вы можете просто щелкнуть правой кнопкой мыши по папке решения и выбрать "Создать".

У нас есть sln-папки для "MainApps" и "Test" (и некоторые другие). Если вам нужны все приложения, вы создадите полное решение. Но если вы не хотите ждать создания тестовых проектов, вы можете просто щелкнуть правой кнопкой мыши и создать папку "MainApps"!

Ответ 2

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

Вы можете вполне законно использовать одни и те же проекты в разных решениях.

Например, у нас есть приложение WinForms, которое имеет такие проекты, как:

  • BusinessObjects
  • DataAccess
  • EnvironmentSupport
  • CustomControls
  • MainUI (на самом деле это не называется, но что это такое)

Построение решения создает все приложение Windows.

Тогда у нас также есть веб-приложение - в собственном решении. Но поскольку мы повторно используем несколько наших проектов, они также появляются в веб-решении, которое имеет:

  • BusinessObjects
  • DataAccess
  • EnvironmentSupport
  • MainWebUI (опять же, это не называется на самом деле)
  • CustomWebControls

Опять же, построение решения создает весь веб-сайт.

Наши проекты появляются в контроле источника только один раз, и все это работает.

Как мы это структурировали, решение в значительной степени приравнивается к приложению, хотя это только свободные отношения. У нас также есть решение для развертывания для приложения Windows, в котором есть все проекты приложений WinForms, а также проект установки (который создает .MSI). Мы сохраняем его отдельно, так как он содержит много дополнительных материалов, которые делают его довольно большим.

НТН.

Ответ 3

Мы используем Пакеты решений довольно немного, чтобы "ассоциировать" проекты в рамках решения. Например, большинство наших "проектов" имеют 3 реальных проекта - реализацию, модульные тесты и интеграционные тесты. Мы помещаем все 3 в одну папку решений. Мы также можем поместить всю инфраструктуру в один и все CAB-модули в другой. В основном, когда у вас есть решение с более 50 проектами, оно помогает организовать их, чтобы вы могли расширять только то, что искали, и находить вещи на основе логической группировки.

Ответ 4

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

Ответ 5

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

Что-то, что мы используем много, это

- > Веб (все веб-проекты) - > Данные (любые проекты, связанные с данными) - > Тест (Все проекты тестирования модулей)

Ответ 6

По моему опыту они просто делают вещи более запутанными, по причине MSDN. Если вы щелкните правой кнопкой мыши по реальной папке в VS, вы получите команду "Открыть папку в проводнике Windows". Если вы щелкните правой кнопкой мыши по папке с решением, ничего. Плюс они склонны испортить подпрограммы, которые сводят к минимуму проводник решений; вещи внутри папок решений не рушится должным образом.

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

Ответ 7

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

Ответ 8

В ситуациях, когда разрабатывается приложение WPF, у разработчиков есть доступ к решению в Expression Blend, папки решений игнорируются в среде Blend. Поэтому все проекты будут отображаться на верхнем уровне.

Кроме того, когда Blend загружает решение, отображается окно с сообщением "Папки решений не поддерживаются. Вложенные проекты будут загружаться нормально". Опцию "Не показывать это сообщение снова" можно проверить, но это все равно несколько неприятно.

Ответ 9

Здесь - связанный вопрос, который я задал некоторое время назад. Один из моих ответов там рассказывает о некоторых преимуществах/недостатках папок решений и о том, как я их сейчас использую.

Ответ 10

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

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