Does the number of projects in a Visual Studio 9 solution impact the solution load and build times?

Question

I'm specifically interested in solution load times & build times - does fewer solutions mean better performance?

Note that I'm not referring to the performance of the built application.

Are load times and build times more efficient when working with a smaller number of projects?

As a guide, we have 50-60 projects in our Visual Studio solution.

Answer 1

(I'm specifically interested in solution load times & build times - does fewer solutions mean better performance?)

Here is related topic by Patrick Smacchia describing benefits of having small number of assemblies (thereafter small number of projects). He talks exactly about how number of assemblies can affect build time and other factors.

I encourage you to read Patrick blog. He has a lot of articles about code componentization.

Advices on partitioning code through .NET assemblies

Lessons learned from the NUnit code base

Hints on how to componentized existing code.

From my personal experience it's a pain to have a solution with a few dozens of projects. IMO having more than 10 projects will lead to noticeable maintenance problems and affect your productivity.

Answer 2

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:

• base project with exceptions and error handling
• business logic
• data access layer - repository
• WebForms OR WinForms OR WPF UI

Some of these I would separate into 3-4 other projects. I would also have NUnit test projects as well.

Answer 3

50-60 sounds like a lot to me. I find that with lots of projects, opening Visual Studio can take a long time. Build time may be bad if you change a project which lots of other projects depend on, but I don't know how different that is between 10 projects with 20 classes in each and 100 projects with 2 projects in each. (In other words, I'm not sure of the per-project overhead in building.) Even when you don't change anything, presumably each project has to detect whether or not it needs to rebuild anything - I can't imagine that's free, but it's hard to give anything more definite without trying it with your own code.

I've been in various companies which have a bunch of projects each with just a few classes in - classes which could very easily be amalgamated into a single project. That has maintenance/manageability benefits as well, in my experience. (Don't do it willy-nilly, of course - just be sensible.)

If you've actually got sensibly-sized projects, just a lot of them, consider splitting the solution up if possible. If they're all tiny projects, consider combining some of them. If you don't find yourself waiting for Visual Studio anyway (opening/building) then don't worry too much.