我们如何设置.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或者安装任何第三方库的情况下构建解决方案。

有什么想法吗？

解决方案

回答

查看其他StackOverflow问题...

• 版本控制中的项目结构
• 最佳实践：协作环境，Bin目录，SVN

回答

我们使用的布局与JP Boodhoo的博客文章"项目目录结构"中所述的布局非常相似。

回答

在我的工作地点，我们有多个项目，每个项目都有自己的子目录，如下所示：
-proj1
--proj1.csproj
-proj2
--proj2.csproj
-proj3
--proj3.csproj
solutionfile.sln

其余的设置看起来还可以，但是我认为我们应该弄清楚如何合并多个项目，例如，多个解决方案之间的共享源库。

回答

如果我正确理解了结构，我认为开发树中将有许多与"工具"和"库"相关的重复项。这些很可能是不同项目可能共享的外部工具和库。

对我们而言，行之有效的是：
`
solutionfile.sln
-src

• 项目名
  ---配置
  ---文档
  ---源文件(代表名称空间的结构)
  -测试
  --testprojectname(通常是每个源项目一个测试项目)
  ---单元测试文件(结构镜像源项目中的结构)
  -lib
  --libraryname(包含库)
  -工具
  `

回答

我在项目中没有工具。工具在网络共享中。是的，这些天磁盘空间很便宜，但是...来吧:)

另外，我在项目名称下有一个数据库脚本文件夹(当它是数据驱动的应用程序时)

当然，设置的方式无关紧要，但是使用合理的组织标准来适应项目并遵循良好的纪律这一事实。无论我们是独奏还是团队合作，这都非常有用。

回答

我们使用这样的结构：

• 引用的程序集
• 共享
• 解决方案
• 测试
• 网

然后只需确保所有项目/解决方案文件仅使用相对路径并且分支工作良好即可。桌面/网站适用于各种类型的项目，测试适用于任何单元测试项目，"解决方案"文件夹中包含每个解决方案的文件夹，其中仅包含解决方案文件。 ReferencedAssemblies包含我们未包含在解决方案中的所有程序集(有时有些本地项目在我们每次构建解决方案时都不想构建，或者诸如rhinomocks或者log4net等第三方程序集。跨多个解决方案使用的任何核心库(数据访问，业务逻辑等)。

回答

TreeSurgeon是一个工具，它将为我们设置目录树，其中包含所有必需的依赖项和框架nant文件。在该链接上，我们还可以找到其原始创建者Mike Roberts撰写的一系列博客文章，其中解释了TreeSurgeon为我们提供的结构背后的一些故意选择，例如为什么可以在lib和工具之间进行复制，为什么必须存在所有依赖项，等等很重要。

我已经有一段时间没有使用它了，所以不记得我是否仍然同意它所做的所有选择，但是我认为我们对此不会有错。

回答

我们也使用TreeSurgeon，对此非常满意。我们的结构如下：

分支

• 建造
• LIB
• 工具

树干

• 同上