I'm very surprised by the accepted answer. I've worked in both environments and have found multiple projects to be beneficial overall. The actual decision is still up to your team (if a single project isn't preventing you from achieving your goals then it's sufficient).
I lean on Uncle Bob's Principles of OOD regarding package management. These aren't very well known (especially compared to his SOLID principles for class design) but they are sensible.
Taken from Uncle Bob's Principles of OOD
The first three package principles are about package cohesion, they
tell us what to put inside packages:
- REP The Release Reuse Equivalency
Principle The granule of reuse is the granule of release.
- CCP The
Common Closure Principle Classes that change together are packaged
together.
- CRP The Common Reuse Principle Classes that are used
together are packaged together.
The last three principles are about the couplings between packages,
and talk about metrics that evaluate the package structure of a
system.
- ADP The Acyclic Dependencies Principle The dependency graph of
packages must have no cycles.
- SDP The Stable Dependencies
Principle Depend in the direction of stability.
- SAP The Stable
Abstractions Principle Abstractness increases with stability.
These align with my personal experience in which leaning towards fewer projects has frequently resulted in problems in my experience:
Fewer packages can result in poor dependency management. Seperate projects/assemblies can help keep internal/private classes and members from being used where they shouldn't be
Typically with many projects you develop a very stable and tested "core" set of libraries, which very rarely change. Keeping these components in their own project (or even solution) can help insulate them from ongoing changes in the higher-level layers.
The large projects that result from using fewer (or a single) project can be very unruly. Visual Studio does not set the expectation that your Project/Solution mirrors your file structure, so an organized large project can still exist as chaos on your drive.
Visual Studio is smart enough to avoid recompiling assemblies which have no changes. As your "core" projects stabilize they will see fewer compilations, which can save time compiling.
Likewise with above, using fewer projects leads to always recompiling code--whether or not it has relevant changes. A one-line change in a very large project will result in full recompilation.
Of course multiple projects can have their issues as well:
You have to be consciencious of your dependencies in order to avoid cyclical references (which .NET handles fairly well, but Visual Studio works to prevent)
Your solutions may become large enough to warrant sub-solutions, which can be tricky to manage
Initial compile times of a solution may be slower
And finally, one rarely used feature in .NET is that a single .DLL can contain multiple Modules (effectively it's several assemblies sharing a single set of metadata). I wouldn't suggest using this, but it's interesting to know it's how things work: http://www.codeproject.com/Articles/9364/Merging-NET-assemblies-using-ILMerge
