Do you believe something like this will work for you?

I’d consider it an advantage for incremental building, but it comes at a terrible price for a full build.

My results: ~2x faster full build when reducing the number of projects from ~80 to ~10.

IMO, the C#/.NET assembly model is broken anyway for incremental builds.

1. visual studio enforces default namespace (just in gui, manual tweak in the .csproj seems to work)

2. Dataset designer uses intermediate directories too when creating it’s namespace (can be worked around with reorganization of source tree)

Wait! This is a comprehensive enterprise-wide application covering distributed business processes. It consists of 11 modules. There were around 50 developers organized into 10 teams. The final application is deployed across a (albeit small) nation on 30 servers, contains around 2000 assemblies with 1.9m LOC in C# (excluding empty lines and comments) + 900 aspx pages.

I believe that the (extreme) partitioning into small projects helped in minimizing the need for coordination among the teams. It did help in managing the project; but the technical challenges had become more and more complex. From having to build a tool that analyzes the dependencies and generates NAnt build file using NVelocity templates, to dealing with memory fragmentation.

The project has completed pilot stage, and the team size has gone down to 15; now we are thinking of consolidating the projects into 30 (3 in each module: UI, Services and Data Access).

I feel embarrassed to confess here about the number of projects. But I asked myself what would I do in the next project of the same size. If I were not forced to confess again on the internet, I would follow the same pattern. [Or perhaps, we won't be as lucky on the next project in terms of performance requirements?]

I am wondering if the comments above missed this aspect of partitioning a system: to support concurrent development.

“I’m not even sure projects/folders are enough, I often want a more virtualized view for example if I’m working on Login I want to see LoginController, its view, the tests, the login parts of the domain mode, LoginService etc. I don’t want to see everything else. So does that mean I put everything in one project and organizing my folders by task/feature?”

See http://douglaspurdy.com/2008/06/21/the-freedom-of-leaving-files-behind/ for an interesting teaser of what the future may look like. Can’t wait for PDC to see what this is all about….

I guess you need some serious ILMerge after that…

One thing I’m now convinced of is there is nothing like a right answer for project/folder structures.

As an example myself and colleagues went through an exercise of changing the entire structure of our main domain projects, changing the folder structure on disk and the structure in the projects/solution(s). However although we all felt we had improved it the result was still frustratingly far from perfect. I tried to explain one part of the restructuring in this blog post (interestingly doesn’t show up well in FireFox, oh well):

http://colinjack.blogspot.com/2007/11/domain-p.html

Project structure is even more difficult than folder structure as you have so many different factors. Reuse of code, dependencies, build time etc. With this in mind I actually think that we need another way of organizing codebases and much better guidance.

I’m not even sure projects/folders are enough, I often want a more virtualized view for example if I’m working on Login I want to see LoginController, its view, the tests, the login parts of the domain mode, LoginService etc. I don’t want to see everything else. So does that mean I put everything in one project and organizing my folders by task/feature? Not sure, I’ve tried that approach and I’m not sure it’s great especially when you have re-use (between applications/teams or even just within a codebase).

Oh and here’s another good link:

http://codebetter.com/blogs/jacob.lewallen/archive/2008/04/01/projects-in-visual-studio.aspx

@Chad
“@Colin: Why does it matter that your domain assembly has a ref to NHibernate? I used to have a problem with it, but I found it was largely a vanity argument (i.e. it didn’t ‘look’ right) but there was no real technical argument there.”

So my domain classes never ever access NHibernate and since dependencies are at the project level that’s how I’d manage it. I could be convinced to weaken on the issue but I’ve yet to feel a compelling need.

Let’s say I don’t mind on that front though, its still possible that the domain/controls/utilities are shared between apps. Of course the argument that apps never share large sections of code (especially domain code) is one some people seem to be going for these days, I don’t necessarily agree 100% with this which shapes my thinking.

“I end up usually having a big Foo.Core assembly that has folders/namespaces where everything is properly separated.”

Yeah I’ve worked on such a project. In that case we had a reasonable amount of developers over a reasonable amount of time and in my view the resulting project ended up quite confusing. Not saying it always would though, this project was confusing in general :)

Other thing to consider is where you have multiple apps and code sharing between them. In those cases bringing in one Foo.Core becomes a bit of an issue (Uncle bobs reuse-release arguments and so on). I know it’s all managable but…