madflatpicker01
My normal rule however is the same as for classes or a method. Make them as small as possible. I would rather have e.g. 10 small projects in a solution, each of which was dedicated to a single pattern or function or subsystem or service, rather than one huge project that has too much messy dependencies.. That way each one can be upgraded, tested, replaced independetly of the others.
Bad idea. You're introducing a lot of friction for benefits that are nothing more than cosmetic.
First, splitting a solution into a large number of small projects significantly increases compilation times.
Second, it has no benefit whatsoever for dependency management, only problems. You don't reduce the overall number of dependencies, you just end up expressing them in multiple places -- a violation of DRY which will bite you hard when you need to change them or to add a new build configuration to your solution.
Third, you shouldn't be upgrading components independently of each other. It means you end up with a version of your code going into production that hasn't been integration tested properly, and doesn't correspond to a single, definitive revision in source control. Set up a continuous integration server instead and get a decent branching and tagging strategy in place.
The key to remember is that assemblies (projects) are a unit of deployment, not a unit oforganisation. The general rule is to have as few projects in your solution as you can get away with. If you need to separate your layers out, that's what namespaces are for.