Menu
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.
800
Some authors propose a number between 15-20 maximum projects in a Visual Studio Solution to be a good compromise.
Research suggests 2-3 projects at a time is optimal for individual focus and collective scheduling. If you're asking people to juggle more than this then you are lowering their productivity. Too Many Projects will damage your business and drive you into a self-perpetuating low productivity fire-fighting culture.
You can have as many projects as you like in a solution, but there can be only one solution open at a time in a particular instance of VS.NET.
A project is contained within a solution. Despite its name, a solution isn't an "answer". It's simply a container for one or more related projects, along with build information, Visual Studio window settings, and any miscellaneous files that aren't associated with a particular project.
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!
127
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.
28
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
