Structuring your .NET solution on the file system

This is probably a subject at the same level of controversy as the one about where to put those pesky curly braces but let’s try setting personal preferences aside and look at it in an objective way.

It’s a fact that developers love consistency or at least in my opinion if they don’t then it is a disqualifying criteria in any job interview. However, another thing that developers tend to love is their own sense of consistency, basically they love being consistent in the way they like the best so it is important to pick one approach and make everyone stick to it.

When it comes to structuring a .NET solution in the filesystem I generally see two approaches being used:

  1. Hierarchical;
  2. Mostly flat.

In the first one its typical to see each part of a project name map to a physical folder, in this scenario, for Contoso.Web.Controls.[cs|k]proj you would expect to find the code in Contoso\Web\Controls\ path. In the mostly flat camp, the code for the previously mentioned project would be found at a folder named Contoso.Web.Controls\.

I’m in the mostly flat camp because I value that the number of parts in a project name does not affect the level at which it will be physically located. This tends to simplify things a lot when it comes to working with the filesystem structure either in build scripts or just for setting common output folders.

Another reason in favor of the mostly flat structure is that it aligns best with what we see more in the .NET open source community, see EntityFramework or ASP. NET MVC. This second part is specially important now that .NET itself made significant steps to become an open source framework.

Couple this second approach with the structure proposed by David Fowler and you have a quick set of rules that will allow you to be consistent within your project while at the same time following the overall trend in the .NET ecosystem.