Структура каталогу для .NET Solution

Нещодавно у нас був візит підрядника, який ставив під сумнів нашу методологію структурування проектів. Зауважте, що я конкретно маю на увазі структуру каталогів. Він запропонував використовувати вказівки Microsoft. Я думав, що зможу створити "керівництво Microsoft. NET структура каталогів проекту .NET" і знайти щось корисне, однак це виявилося не так. На даний момент ми робимо щось подібне:

[Company.System.Feature]
  |-doc
     |Sandcastle project
  |-lib
     |Nuget packages
  |-src
    |-Project1 e.g. web
    |-Project2 e.g. business logic
    |-UnittestProject1
    |-Specs

Папка doc містить рішення Sandcastle, як описано тут: https://www.codeproject.com/Articles/15176/Sandcastle-Help-File-Builder (див. Абсолютний та відносний контури). Тому папка doc містить папку Help, яка містить створений файл довідки. Папка lib містить усі пакунки Nuget.

Чи є вказівки Microsoft, які рекомендують структурувати рішення? Я тут заглянув: /programming/789389/project-structure-for-c-sharp-development-effort/789554?noredirect=1#comment86756309_789554 серед інших місць. Більшість прочитаних нами статей та питань, здається, створені у 2007-2009 роках. Я вважаю, що Nuget був представлений у 2010 році. Чи є вказівки Microsoft? Я читав про щось під назвою Дерево Хірург, однак, схоже, це вже не існує: https://archive.codeplex.com/?p=treesurgeon .

Я використовую TFS; Круїз-контроль і DDD - це суттєво.

c# visual-studio

— w0051977
джерело

Структури каталогів - це дуже смак. Використовуйте структуру папок, яка найбільш чітко визначає наміри вашого проекту / організації.

— Роберт Харві

Крім того, наступного разу, коли хтось скаже, що ви повинні дотримуватися "Правил Microsoft" про щось, попросіть цю особу надати ці вказівки або покаже, де ви можете їх знайти. В іншому випадку це марні поради.

— Роберт Харві

непарний біт ставить натільні пакунки в lib замість пакунків

— Еван

@Ewan, nuget пакети навіть більше не належать packagesдля проектів у стилі dotnetcore та VS2017. Зараз вони живуть у objдовідниках проектів .

— Девід Арно

pff! модернізація?!?!? звучить так, що це може зламати речі

— Еван

На MSDN є кілька дуже старих офіційних вказівок . Вони, однак, застаріли. Як зазначається на сторінці, " Цей вміст застарів і більше не підтримується. Він надається ввічливістю для людей, які все ще використовують ці технології ". Тому я рекомендую вам уникати цих рекомендацій.

Була спроба визначити загальну структуру рішення за допомогою проектних лісів . Це більше орієнтоване на F #, а не на C #. Це насправді не злетіло, і в наші дні мало ознак розвитку ідей.

Найактивніший і найсучасніший набір керівних принципів підтримує Девід Фоулер, який є розробником компанії Microsoft в команді ASP.NET. Ці вказівки використовуються багатьма в Microsoft, включаючи команди Roslyn (компілятор C # і VB.Net). Ви можете зробити набагато гірше, ніж прийняти такий підхід.

— Девід Арно
джерело

Я побачив перші два посилання, але не третє. +1 для третього посилання. Чи можу я помістити весь проект Sandcastle в папку «Документи» або просто файли довідки, що генеруються проектом Sandcastle? Не впевнений, чому цю відповідь було оскаржено.

— w0051977

Справедливості, на кожній сторінці, яка не включена в нову документаційну систему Microsoft, розміщено штампом словами "цей вміст застарів і більше не підтримується". Це не означає, що там немає корисної інформації.

— Роберт Харві

Ви поставили б Спекуляції? У папці Tests або в каталозі під назвою Specs (у тому ж каталозі, що і у папці src)? Я думаю, це насправді не має великого значення.

— w0051977

@RobertHarvey: Досить справедливо, але посилання на цю сторінку самостійно, не маючи додаткового резервного копіювання, також не є підставою для зміни структури папки проекту, якщо інша вже створена.

— Флатер

Ви можете ознайомитись з практичними рекомендаціями Девіда Фоулерса у більшості проектів з відкритим кодом на GitHub, наприклад Enity Framework .

— pfx