What is the optimum number of projects in a Visual Studio 2008 solution?
We have one Visual Studio 2008 solution that is around 50 projects right now. It will likely continue to grow as the bulk of the projects within the solution consist of plugin assemblies for the main application.
If it seems like ‘too many projects’ in one solution then how would you go about determining which projects should be grouped together in a solution? Given our example of approximately 50 projects in one solution with the bulk of the projects being plugins and with the number of plugins likely to grow, how should solutions be structured? Should all of the plugins be placed in their own solution? How should the organization change when the number of plugins in the plugins solution hits the magic number of ‘too many’?
We don’t have any issues with this many projects in the solution … it loads quickly, it builds quickly, it uses a reasonable amount of memory, and doesn’t cause VS2008 to crash or bump up against any VS2008 bugs.
I’ve looked for documentation from Microsoft (there doesn’t seem to be any) and Google searches yeild recommendations from ‘every project gets its own solution’ to ‘place all projects in a single solution.’ Both extremes seem to be absurd. I’m looking for some reasonable guidance in the middle.
There have been other questions on Stackoverflow related to the maximum you’ve seen. That’s not quite the same as what the optimum would be.
This is akin to discussions such as ‘how many functions should I have in a class?’ and ‘should each enum be defined in its own .cs file?’.
I would be interested to know how many classes each of your projects has. You can think of your classes, projects and solutions as organisational units. They are there to make your life easier, and to allow you (and your team) to break the overall project into managable conceptual chunks.
If VS2008 isn’t complaining, and you and your developers have no problem with 50 projects in one solution then I would not worry about it.
That said, it does sound like a rather large number – but then we know nothing about the size of your overall codebase so it’s hard to comment further.