views:

1238

answers:

8

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?

+5  A: 

Check out these other StackOverflow questions...

Steven Murawski
+8  A: 

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

Macka
That link is behind some kind of sign-up wall.
Scott Whitlock
Thanks for letting me know - the blog had been moved - should work now.
Macka
A: 

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.

ARKBAN
A: 

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

Curro
A: 

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.

HollyStyles
Tools can have different versions. If your old projects depend on version 1 of the tool, and you decide to upgrade to version 2 of the tool, you need to upgrade all the old projects to support version 2 of the tool. Checking everything in to source control, makes life a bit easier. :-)
Fossmo
I completely agree Fossmo. Initially I didn't like the idea of duplicating the tools binaries in every project I create. But it reduces the issues you can have in situations like that and the disk cost is really very minimal.
Nathan Palmer
different versions can be shared just fine too, so not including them in the project tree doesn't mean you have to upgrade at all.
HollyStyles
+1  A: 

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.

Chris Shaffer
+2  A: 

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.

Alex Scordellis
A: 

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