Соглашение об именах для решений и проектов Visual Studio

Ответ 1

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

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

Ответ 2

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

\trunk
  [CompanyName]
    CompanyName.Product1.sln
    CompanyName.Product2.sln
    [Product1]
        [Project1]
          CompanyName.Product1.Project1.csproj
        [Project2]
          CompanyName.Product1.Project2.csproj
    [Product2]
        [Project3]
          CompanyName.Product2.Project3.csproj

Ответ 3

Что касается имен файлов - я предпочитаю, чтобы имя моего проекта совпало с именем сборки сборки, потому что это значительно облегчает понимание того, что что-то производит. Выполнение списка каталогов намного быстрее, чем поиск файлов csproj в дереве для тех, которые создают сборку, о которой я забочусь.

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

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

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

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

Ответ 4

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

Ответ 5

Выглядит хорошо.

Следует отметить, что по умолчанию пространство имен по умолчанию в проекте Visual Studio - это просто имя проекта. Несомненно, это означает, что имена ваших проектов, подобных вашим пространствам имен, являются "способом Visual Studio".

Решения наиболее естественно называются после продукта/проекта. Как вы указываете.

Ответ 6

Я считаю это лучше

\trunk
  [CompanyName]
    [Product1]
      CompanyName.Product1.sln
      [Main] --Optional
        CompanyName.Product1.csproj
      [Project1]
        CompanyName.Product1.Project1.csproj
      [Project2]
        CompanyName.Product1.Project2.csproj
    [Product2]
      CompanyName.Product2.sln
      [Main] --Optional
        CompanyName.Product2.csproj
      [Project1]
        CompanyName.Product2.Project3.csproj
      [Project2]
        CompanyName.Product2.Project2.csproj
      [Project3]
        CompanyName.Product2.Project2.csproj

Зачем? Потому что, когда вы получаете код из репозитория, вы получаете, например, каталог "Product1", он содержит все, что вам нужно для работы. Каталог [Main] содержит базовое пространство имен по умолчанию, обычно это exe или основной проект. Это необязательно.