Excellent tips.

On point 2. Is there any way to control build order other than via project dependencies? In a solution with lots of projects, sometimes a small change means all dependent projects are recompiled. This increases local build time significantly. So, I copy all projects output to a ReferencedAssemblies folder, and reference dependencies from there (with CopyLocal = false). But when I build a solution, the dependent projects still build, even if no changes have been made. I’d like to decide the project build order without using dependency ordering. Is this possible? I’m using VStudio 2008.

Thank you.

I’m on a laptop supplied by our client – not too much I can do in that side. I forgot about the /m switch, thanks!

Thanks! We’ll keep an eye on it. On the other hand, I don’t see a situation where dev’s shouldn’t have their own DB. Sharing DB’s is messy.

Here’s my case study – a recent gig we went from 72 to 12 projects. Many of the projects were exactly one file, even though there were only 4 deployed applications. Pointless, in that case.

If a team has problems with understanding layers and responsibilities, and you have to force a project structure to make that understanding, then I’d say you have other bigger problems. I’d rather the focus be on deployments and dependencies between deployments rather than trying to enforce layers, or “i don’t want to reference System.Data from my Domain project”. That’s hand-holding.

Don’t get me wrong, I’m not advocating cutting along EVERY single line. People need to determine their own priorities and then cut where and only where appropriate based on those priorities, whether they be build time, test time, published abstraction version stability, tiering, partitioning, IDE performance when working on subsets of projects, all sorts of options.

The blanket statements just need to stop because they aren’t helping anyone and will actively harm many. The first thing to happen on a blindly-minimized-project-count solution with a large enough number of tests in it is that the devs will stop running the tests, and we all know where that leads. And, no, the fact that the build process will still run them is inadmissible because, while true, it kinda misses the point.

It would be great if you could share your build scripts.

You may be doing this, but msbuild /m is your friend. Also, I recently upgraded my workstation which was a Core 2 Duo with 4 GB of RAM — not a bad box — to a low end Core i7 with 6GB of RAM. A previous large .NET solution that took ~35 secs to compile now compiles in 10 secs flat. Hardware is cheap relative to developer time.

Also, are you running your unit tests in parallel or single threaded? For non-sequential tests, it would be interesting to see what parallelizing your tests did.