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 perfor

Answer 1

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.

Answer 2

Late to the party, but none of the answers so far mentions build configurations. You CAN have lots of projects in your solution without them all being built every time you run. Click on the Debug/Release combo and create a new build configuration - there you can decide which projects you want to build or not.

Why do this? I do it so that I can 'Go to definition' at will, and so that I can rapidly swap projects in and out of my build without going through all the Add project pain.

Also, note that if you have solution folders, you can right click and build on the folder, which will build all the projects in the folder.

Answer 3

(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 4

The general practice I try to keep to is 4-5 projects per solution.

• Business Logic
• Communications Layer (Server-related)
• User Interface
• Testing Project to utilize/test the other three projects

This generally fits our style and how we can go about implementing it. If necessary, we can include other things in there too, but those instances aren't nearly as common as these four for us.

Answer 5

It's a bad idea to have too many projects inside your solution. It affects build time. See this article that does a comparison of build times with several build tools. According to the article, Visual Studio takes 2 seconds per project, even if the project is not part of the build.

This also matches my experience, that Visual Studio is one of the slowest build tool available. Between Visual Studio 6 and 2006, my build time has moved from one minute to 5 minutes for a relatively simple C project.

Answer 6

The problems I see when you create a lot of small projects are :

1/ Encapsulation : A class, a method or a property that you want to share between two projects have to be public and thus to be visible from everywhere. The more projects you have, the more likely it is that you are disclosing some secrets...

2/ Total number of assemblies : As Aku wrote, fewer projects meens fewer assemblies. Since each project copy locally the assemblies they use, you could get up to ( n * (n - 1)) / 2 assemblies in your folders (49 copies of assembly 1, 48 of assembly 2, ...). For 50 projects, this is 1176 files ! => Ok, you probably have a lot less (200 ?), but it is still enought to get a copy or two outdated here and there...