What is the optimum number of projects in a Visual Studio 2008 solution?

Question

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.

Answer 1

42.

Answer 2

I suppose that's a typical YMMV.

Answer 3

I'd say that you need at least 1 project for each layer on your system. If you need more projects, maybe it's a design problem. Meaning you can either "Over"-design or "Under"-design the application.

I nowdas use the following layers:

DataLayer - Responsible for the underlying data structure ( the database ). In the latest cases having the LINQ and partial classes for this in this project.

Interfaces - Having a layer for all interfaces, this to help extendabillity and not having to rely on some other layers to use these interfaces.

Logic - This defines itself, the business logic

GUI / Front - The Graphical user Interface ( Code )

These layers are the Minimum other Layers that COULD be possible would be Localization and other project that might grow.

But rahter simplify to directories and namespaces than using to many projects!

Answer 4

Obviously when you get to 500 then you're starting to look at "too many" it becomes impractical even to manage it.

I might suggest that you analyse "what really constitutes my application" and package that as a single solution. Plugins are rarely considered part of the base application but add-ons to the base functionality.

If the application would cease to be useful without certain plugins, then include those in the base solution.

Other plugins might be grouped on Genre... much like the playlists on your iPod. What does each plugin achieve on a more general level? (These are obviously rhetorical questions) I would group plugins together in natural groups - much like PhotoShop plugins as they group on the menu. i.e. do they affect 3D, do they affect color, do they affect geometric effects, do they affect distortion etc etc.

Answer 5

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.

Answer 6

When I see a slow down, I tend to create a solution that has references to built versions (assemblies) of dependent projects rather than the project files (for any projects that I don't need to see the source code). I only open the source for projects I am working on - surely nobody needs to work on the source of 50 projects at one time.

If you are already referencing the dependent assemblies rather than source, then I think it is just a matter or organizational preference (organize in a way that is easiest for you to understand and maintain).