你如何设置你的.NET开发树？

How do you set up your .NET development tree? I use a structure like this:

你如何设置你的.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

The sign "-" marks directories.

符号“ - ”标记目录。

I think it's very important to have a good structure on this stuff. You should be able to get the source code from the source control system and then build the solution without opening Visual Studio or installing any third party libraries.

我认为在这些东西上建立一个好的结构是非常重要的。您应该能够从源代码控制系统获取源代码,然后在不打开Visual Studio或安装任何第三方库的情况下构建解决方案。

Any thoughts on this?

有什么想法吗?

8 个解决方案

#1

We use a very similar layout as covered in JP Boodhoo's blog post titled Directory Structure For Projects.

我们使用了一个非常相似的布局,如JP Boodhoo的博客文章“目录结构项目”中所述。

#2

Check out these other * questions...

看看这些其他*问题......

Structure of Projects in Version Control

版本控制中的项目结构

Best Practice: Collaborative Environment, Bin Directory, SVN

最佳实践:协同环境,Bin目录,SVN

#3

TreeSurgeon is a tool that will set up a directory tree for you, with all the required dependencies and a skeleton nant file. At that link, you can also find a series of blog posts by its original creator, Mike Roberts, explaining some of the deliberate choices behind the structure that TreeSurgeon gives you, e.g. why it's OK to have duplication between lib and tools, why it's important to have all dependencies present etc.

TreeSurgeon是一个为您设置目录树的工具,包含所有必需的依赖项和一个骨架nant文件。在该链接中,您还可以找到其原始创建者Mike Roberts发布的一系列博客文章,解释TreeSurgeon为您提供的结构背后的一些有意选择,例如:为什么在lib和工具之间进行重复是可以的,为什么让所有依赖项都存在等很重要。

I haven't used it in a while so can't remember if I still agree with all the choices it makes, but I don't think you can go far wrong with it.

我有一段时间没有使用它,所以不记得我是否仍然同意它所做出的所有选择,但我认为你不能错过它。

#4

We use a structure like this:

我们使用这样的结构:

CompanyNameOrCoreProjectName
- Branch
  - BranchName
    - CopyOfTrunk
- Trunk
  - Desktop
  - ReferencedAssemblies
  - Shared
  - Solutions
  - Test
  - Webs

CompanyNameOrCoreProjectName Branch BranchName CopyOfTrunk Trunk Desktop ReferencedAssemblies共享解决方案测试网站

Then just make sure that all project/solution files only use relative paths and branching works well. Desktop/Webs are for projects of the respective types, Test is for any unit test projects, Solutions folder has a folder for each solution with only the solution file in it. ReferencedAssemblies holds all of the assemblies that we don't include in the solution (these are sometimes local projects that we just don't want to build every time we build the solution or third party assemblies like rhinomocks or log4net, etc. Shared is for any of the core libraries (data access, business logic, etc) that are used across several solutions.

然后确保所有项目/解决方案文件仅使用相对路径,并且分支工作正常。桌面/ Web适用于各种类型的项目,Test适用于任何单元测试项目,Solutions文件夹具有每个解决方案的文件夹,其中只包含解决方案文件。 ReferencedAsmblies包含我们未在解决方案中包含的所有程序集(这些程序集有时是我们在构建解决方案时不想构建的本地项目或者像rhinomocks或log4net等第三方程序集等。共享用于跨多个解决方案使用的任何核心库(数据访问,业务逻辑等)。

#5

At my place of work we have multiple projects, where each project gets its own sub-directory, like so: -proj1
--proj1.csproj
-proj2
--proj2.csproj
-proj3
--proj3.csproj
solutionfile.sln

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

The rest of your setup looks okay, but I think you should figure out how you would incorporate multiple projects, for example a shared source library between multiple solutions.

您的其余设置看起来没问题,但我认为您应该弄清楚如何合并多个项目,例如多个解决方案之间的共享源库。

#6

If I understand your structure correctly, I think you are going to have many duplicates in your dev tree related to "tools" and "lib". Most likely these are external tools and libraries that might be shared by different projects.

如果我正确地理解了你的结构,我认为你的开发树中会有很多与“tools”和“lib”相关的重复项。很可能这些是可能由不同项目共享的外部工具和库。

Something that works well for us is:
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

对我们有用的东西是:solutionfile.sln -src --projectname --- config --- doc ---源文件(表示名称空间的结构)-test --testprojectname(通常是每个源项目的测试项目) - --unit test files(结构镜像源项目中的结构)-lib --libraryname(包含库)-tools

#7

I don't have tools within the project. Tools are in a network share. Yes disk space is cheap these days but... come on :)

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

Also I have a database script folder below projectname (when it's a data driven app)

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

Of course it doesn't matter so much how you're set-up, but the fact that a logical organised standard is used to suit the project and adhered to with good discipline. This is useful whether you're solo or on a team.

当然,你如何设置并不重要,但是使用逻辑有组织的标准来适应项目并坚持良好的纪律。无论您是单人还是团队,这都很有用。

#8

We also use TreeSurgeon and are quite happy with it. Our structure looks like:

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

Branch

build
lib
src
- < various src directories for apps, tests, db migrations, etc.)

src <用于应用程序,测试,数据库迁移等的各种src目录。)< p>

tools

Trunk

Same as above

与上面相同

#1