How to split a solution into projects

Yesterday, a colleague of mine asked for some guidance on how to partition a Visual Studio solution into individual projects. Instead of simply answering his email I thought that blogging about it may be useful for others as well, so here are my rules:

• In general, have as few projects as possible. Having many projects considerably slows down compiling, but also causes the startup time of the corresponding application to increase. Loading 10 small assemblies is much slower than loading one big assembly. Jeremy (D. Miller) mentioned this already in this post, but Patrick Smacchia, the author of NDepend, provides some good proof of if it here.
• Web Application or Web Site projects should, for obvious reasons, always have their own project. However, make sure you move as much logic out of it if you consider automatic testing important.
• Never use logical architectural layers as a reason for partitioning your code in multiple projects. Likewise, never use it to prevent classes from accessing their internal members. Consider using Visual Studio 2010's Layer Diagram for verifying dependencies or use NDepend's excellent analysis engine. You can still use folders within your projects to maintain a clear logical separation.
• Only split up your code if you need to deploy parts of your system separately.
• If you like to run your unit and integration tests from different daily builds, it may be wise to put them in separate projects. We typically run the fast and independent unit tests as part of our Continuous Integration build, and only run the database-touching integrations tests from the Nightly Build. In Team Build, the easiest way for specifying which tests to run is by specifying the name of the assembly containing the test classes.
• Consider the guidelines written down in Team Development with Visual Studio Team Foundation Server. It provides some very good alternatives that also account for branching and release management. And don't let yourself scared off by the use of TFS. These guidelines apply to all source controlled environments.