Как настроить дерево разработки .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 или не устанавливая какие-либо сторонние библиотеки.

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


.net c# development-environment
person Fossmo    schedule 16.09.2008    source источник

Ответы (8)


arrow_upward
8
arrow_downward

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

person BigJump    schedule 16.09.2008
comment
Эта ссылка находится за какой-то стеной регистрации. - person Scott Whitlock; 07.08.2009
comment
Спасибо, что сообщили мне - блог был перемещен - теперь он должен работать. - person BigJump; 16.08.2009

arrow_upward
5
arrow_downward

Ознакомьтесь с этими другими вопросами о StackOverflow ...

person Steven Murawski    schedule 16.09.2008

arrow_upward
2
arrow_downward

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

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

person Alex Scordellis    schedule 16.09.2008

arrow_upward
1
arrow_downward

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

  • CompanyNameOrCoreProjectName
    • Branch
      • BranchName
        • CopyOfTrunk
    • Trunk
      • Desktop
      • Ссылки
      • Общий
      • Решения
      • Контрольная работа
      • Сети

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

person Chris Shaffer    schedule 16.09.2008

arrow_upward
0
arrow_downward

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

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

person ARKBAN    schedule 16.09.2008

arrow_upward
0
arrow_downward

Если я правильно понимаю вашу структуру, я думаю, у вас будет много дубликатов в вашем дереве разработки, связанных с «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

person Curro    schedule 16.09.2008

arrow_upward
0
arrow_downward

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

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

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

person hollystyles    schedule 16.09.2008
comment
Инструменты могут иметь разные версии. Если ваши старые проекты зависят от версии 1 инструмента, и вы решили обновить его до версии 2, вам необходимо обновить все старые проекты для поддержки версии 2 инструмента. Проверка всего в системе контроля версий делает жизнь немного проще. :-) - person Fossmo; 16.09.2008
comment
Полностью согласен с Фоссмо. Изначально мне не нравилась идея дублировать двоичные файлы инструментов в каждом проекте, который я создаю. Но это уменьшает количество проблем, которые могут возникнуть в подобных ситуациях, а стоимость диска действительно минимальна. - person Nathan Palmer; 05.09.2009
comment
разные версии также могут совместно использоваться, поэтому отсутствие их в дереве проекта не означает, что вам вообще нужно обновляться. - person hollystyles; 06.09.2009

arrow_upward
0
arrow_downward

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

Филиал

  • строить
  • библиотека
  • src
    • < various src directories for apps, tests, db migrations, etc.)
  • инструменты

Багажник

  • То же, что и выше
person Community    schedule 16.09.2008