Возможно, вы захотите прочитать серию Майка Робертса, Как настроить дерево разработки .Net . На мой взгляд, способ, которым Visual Studio делает это по умолчанию, по сути, нарушен.
Single * .pdf: Как настроить дерево разработки .Net
По сути, ваша структура каталогов должна выглядеть следующим образом:
Meta/Development Root
Обычно отображается в корень системы контроля версий.
Solution
Один каталог, содержащий все ваше решение. Должен быть назван так, чтобы соответствовать решению.
Solution.sln
Сам файл решения.
nant.build
Файл сборки nAnt для решения.
lib
Каталог lib
содержит сторонние сборки / dll, на которые ссылаются различные проекты в вашем решении. Он находится под контролем источника. Ссылки на проекты должны указывать здесь.
tools
Каталог tools
содержит все сторонние инструменты, необходимые для построения вашего решения. Это тоже находится под контролем источника. Каталог tools
должен содержать версии nAnt
, nUnit
и т. Д., Используемые вашим проектом & mdash; и ваши сценарии сборки должны ссылаться на них, а не на версии, установленные на компьютере разработчика.
bin
Каталог bin
содержит выходные данные процесса сборки решения. Каждый проект должен быть настроен так, чтобы он указывал здесь.
debug
отладочная сборка
release
Выпуск сборки
obj
В идеальном мире здесь указывается obj
каждого проекта, а также нет места в дереве исходных текстов. К сожалению, Visual Studio не предлагает официального способа сделать это (хотя, как мне сказали, VS можно взломать, если вы достаточно изобретательны).
src
Каталог src
является корневым каталогом для фактического исходного кода вашего решения.
project1
Каталог для project1
.
project
.csproj`
Файл проекта.
*.cs
и др. Файлы. Исходные файлы.
- ...
project-n
Как структурировать отдельные проекты, я думаю, это совершенно отдельная тема, но должно быть, WRT и для решения, и для отдельных проектов соответствует между пространством имен и иерархией файловой системы. Если для конкретного проекта требуется сторонняя сборка, которая недоступна для других проектов в решении, для каждого каталога таких проектов может быть задан аргумент в его собственную директорию lib
, но при этом сторонние сборки будут разбросаны по всему источнику. дерево и так не рекомендуется.