Recommended number of projects in Visual Studio Solution

Question

We are starting to develop new application that will include something like 30-50 projects developed by about dozen of developers with C# in MS Visual Studio.

I am working on componentize the application modules in order to support the architecture and enable parallel work.

We have argue: how many solutions should we have?

Some claim that we should have 1-2 solution with 15-30 projects each. Some claim that we need a solution per component that means about 10-12 solutions with about 3-6 projects each.

I would be happy to hear pros/cons and experience with each direction (or other direction thereof)

Thanks

Answer 1

I don't think the actual number of solutions matters. Much more important is that you break the thing up along functional lines. As a silly, contrived example if you have a clutch of libraries that handles interop with foreign web services, that would be a solution; an EXE with the DLLs it needs to work would be another.

Answer 2

I think you should not exaggerate your number of projects/solutions. Componentize what can
and will be reused, otherwise don't componentize! It will only make things less transparent and increase build times. Partitioning can also be done within a project using folder or using a logical class structure.

Answer 3

You want to maintain project references. If you can safely break up your solution with two or more discrete sets of projects that depend on each other, then do it. If you can't, then they all belong together.

Answer 4

Solutions are really there for dependency management, so you can have project in more that one solution, if more than one thing depends on it. The number of solutions should really depend on your dependency graph.

Edit: This means you shouldn't be sticking projects that are not dependent on each other into the same solution, as it creates the illusion of dependency which means someone could create a real dependency when too projects should really be independent.

Answer 5

Only thing about so many projects in one solution is that the references and build order start to get confusing.

As a general rule I'd gravitate toward decreasing the number of projects (make the project a little more generic) and have devs share source control on those projects, but separate the functionality within those projects by sub-namespaces.

Answer 6

I've worked on a solution with close to 200 projects. It's not a big deal if you have enough RAM :).

One important thing to remember is that is projects depend on each other (be it with Dependencies or References), they should probably be in the same solution. Otherwise you get strange behavior when different projects have different dependencies in different solutions.

Answer 7

You should have as many as you need. There is no hard limit or best practice. Practice and read about what projects and solutions are and then make the proper engineering decisions about what you need from there.

Answer 8

We have a solution that has approximately 130 projects. About 3 years ago when we are using vs.net 2003 it was a terrible problem. Sometimes solution and VSS were crashing.

But now with VS.NET 2005 it's ok. Only loading is taking much time. Some of my coworkers unloading projects that they don't use. It's another option to speed up.

Changing build type to release is an another problem. But we have MSBuild scripts now. We do not use relese build of VS.NET no more.

Answer 9

It has been said in other answers however it is probably worth saying again.

Project dependencies are good in that they can rebuild dependent projects if the dependency has a change.

If you do a assembly file dependency there is no way that VS or MSBuild is going to know that a string of projects need to be built. What will happen is that on the first build the project that has changed will be rebuilt. If you have put the dependency on the build output then at least on the second build the project dependent on that will build. But then you have an unknown number of builds needed to get to the end of the chain.

With project dependencies it will sort it all out for you.

So the answer that says have as many (or few) as needed to ensure project dependencies are used.

If your team is broken down into functional areas that have a more formal release mechanism rather than checkin of source code then splitting it down those lines would be the way to go, otherwise the dependency map is your friend.

Answer 10

I've worked on products on both extremes: one with ~100 projects in a single solution, and one with >20 solutions, of 4-5 projects each (Test, Business Layer, API, etc).

Each approach has its advantages and disadvantages.

A single solution is very useful when making changes - its easier to work with dependencies, and allows refactoring tools to work well. It does however, result in longer load times and longer build times.

Multiple solutions can help enforce separation of concerns, and keep build/load times low, and may be well suited to having multiple teams with narrower focus, and well defined service boundaries. They do however, have a large drawback when it comes to refactoring, since many references are file, not project references.

Maybe there's room for a hybrid approach use smaller solutions for the most part, but create a single including all projects for times when larger scale changes are required. Of course, you then have to maintain two separate solutions...

Finally, the structure of your projects and dependencies will have some influence on how you organize your solutions.

And keep in mind, in the long run RAM is cheaper than programmer time...