Как настроить дерево разработки .NET? [закрыто]

Как настроить дерево разработки .NET? Я использую такую ​​структуру:

-projectname
--config (where I put the configuration files)
--doc    (where I put all the document concerning the project: e-mails, documentation)
--tools  (all the tools I use: Nunit, Moq)
--lib    (all the libraries used by the solution: ninject or autofac)
--src
---app   (sourcefiles)
---test  (unittests)
solutionfile.sln
build.csproj

Знак «-» обозначает каталоги.

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

Есть мысли по этому поводу?

16.09.2008 12:12:34
8 ОТВЕТОВ
РЕШЕНИЕ

Мы используем очень похожий макет, как описано в блоге JP Boodhoo под названием « Структура каталогов для проектов» .

8
5.02.2015 16:32:10
Эта ссылка находится за какой-то стеной регистрации.
Scott Whitlock 7.08.2009 00:56:16
Спасибо, что сообщили мне - блог был перемещен - должен работать сейчас.
BigJump 16.08.2009 08:55:27

На моем рабочем месте у нас есть несколько проектов, каждый из которых имеет свой собственный подкаталог, например: -proj1
--proj1.csproj
-proj2
--proj2.csproj
-proj3
--proj3.csproj
solutionfile.sln

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

0
16.09.2008 12:25:42

Если я правильно понимаю вашу структуру, я думаю, что в вашем дереве разработки будет много дубликатов, связанных с «tools» и «lib». Скорее всего, это внешние инструменты и библиотеки, которые могут использоваться разными проектами.

У нас хорошо работает:
solutionfile.sln
-src
--projectname
---config
---doc
---source files (structure representing namespaces)
-test
--testprojectname (usually, a test project per source project)
---unit test files (structure mirroing the structure in the source project)
-lib
--libraryname (containing the libraries)
-tools

0
16.09.2008 12:32:42

У меня нет инструментов в рамках проекта. Инструменты находятся в сетевом ресурсе. Да, дисковое пространство дешевое в наши дни, но ... давай :)

Также у меня есть папка сценария базы данных под именем проекта (когда это приложение, управляемое данными)

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

0
16.09.2008 12:33:05
Инструменты могут иметь разные версии. Если ваши старые проекты зависят от версии 1 инструмента, и вы решили обновить его до версии 2, вам необходимо обновить все старые проекты для поддержки версии 2 инструмента. Проверка всего в системе контроля версий делает жизнь немного проще. :-)
Fossmo 16.09.2008 15:36:50
Я полностью согласен с Фоссмо. Изначально мне не нравилась идея дублировать двоичные файлы инструментов в каждом проекте, который я создаю. Но это уменьшает проблемы, которые могут возникнуть в подобных ситуациях, и стоимость диска действительно очень минимальна.
Nathan Palmer 5.09.2009 18:56:58
с разными версиями тоже можно поделиться, поэтому, если вы не включите их в дерево проекта, это вовсе не означает, что вам придется обновляться.
Black Squirrel 6.09.2009 18:01:26

Мы используем такую ​​структуру:

  • CompanyNameOrCoreProjectName
    • Ветвь
      • BranchName
        • CopyOfTrunk
    • Хобот
      • рабочий стол
      • ReferencedAssemblies
      • Общий
      • Решения
      • Контрольная работа
      • Полотна

Затем просто убедитесь, что все файлы проекта / решения используют только относительные пути и ветвление работает хорошо. Desktop / Webs предназначены для проектов соответствующих типов, Test - для любых проектов модульного тестирования, папка Solutions содержит папку для каждого решения, содержащего только файл решения. ReferencedAssemblies содержит все сборки, которые мы не включаем в решение (иногда это локальные проекты, которые мы просто не хотим создавать каждый раз, когда собираем решение или сторонние сборки, такие как rhinomocks или log4net и т. Д. Shared предназначен для любая из основных библиотек (доступ к данным, бизнес-логика и т. д.), которые используются в нескольких решениях.

1
16.09.2008 12:39:17

TreeSurgeon - это инструмент, который создаст для вас дерево каталогов со всеми необходимыми зависимостями и файлом скелета. По этой ссылке вы также можете найти серию постов в блоге его первоначального создателя Майка Робертса, объясняющих некоторые из преднамеренных решений, лежащих в основе структуры, которую предоставляет TreeSurgeon, например, почему нормально иметь дублирование между lib и инструментами, почему это важно наличие всех зависимостей и т. д.

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

2
16.09.2008 12:58:52

Мы также используем TreeSurgeon и довольны этим. Наша структура выглядит так:

Ветвь

  • строить
  • Lib
  • ЦСИ
    • <различные каталоги src для приложений, тестов, миграции баз данных и т. д.)
  • инструменты

Хобот

  • То же, что и выше
0
16.09.2008 13:17:30