How do you set up your .NET development tree?

Question

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

-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.

Any thoughts on this?

Answer 1

Check out these other StackOverflow questions...

• Structure of Projects in Version Control
• Best Practice: Collaborative Environment, Bin Directory, SVN

Answer 2

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

Answer 3

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

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.

Answer 4

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.

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


Answer 5

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)

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.

Answer 6

We use a structure like this:

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

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.

Answer 7

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.

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.

Answer 8

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

Branch

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

Trunk

• Same as above