I\'m specifically interested in solution load times & build times - does fewer solutions mean better performance?
Note that I\'m not referring to the perfor
I depends on your project, most of the time I work with 10-15. The less projects the shorter the build time.
Projects I typically have are:
Some of these I would separate into 3-4 other projects. I would also have NUnit test projects as well.
And some Microsoft words...
http://tfsguide.codeplex.com/Wiki/View.aspx?title=Chapter%203%20-%20Structuring%20Projects%20and%20Solutions%20in%20Source%20Control
In my opinion it's just a matter of personal organizzation and order. If you feel like to have a lot of projects that are connected in some way each other under the same solution, you can do it. I think you just have to consider if you really need them all. There's no such thing as a magical maximum number of projects per solution
I work on a project with a large number of projects, in the realm of 50-60, and I have found that the long load times are acceptable compared with the problems associated with developer lazyness / forgetfulnes.
Lots of the projects are dependent on base libraries, and thus need to be rebuilt when the base library is changed. As the projects can be in some flux at any given time, having developers only work on a subset means that if they are lazy they will not rebuild the entire application when an update is received from the CM tool. They can then spend a huge amount of time trying to fix things realizing why things are broken. This is all solved if the entire dependency tree is known by VS and a quick build-all can make it all work properly.
I realize that a excellent developer will know this and do it by default, but not everyone is great, and sometimes even the greats have off days.