18

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 solutions 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)

CJBS
  • 13,354
  • 5
  • 76
  • 124
Ragoler
  • 1,167
  • 3
  • 13
  • 20
  • Dupe of http://stackoverflow.com/questions/338067/what-is-the-optimum-number-of-projects-in-a-visual-studio-2008-solution – Robert S. Feb 09 '09 at 21:42
  • I actually think the answers to this one were more helpful. No one voted up '42' – BigSandwich Feb 09 '09 at 21:46
  • This question is a lot better, I think. Does that expose a flaw in the "dupe" equation? Maybe. I think 42 is still a good answer. – Robert S. Feb 09 '09 at 21:53

12 Answers12

28

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...

Nader Shirazie
  • 10,601
  • 2
  • 34
  • 43
18

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 two projects should really be independent.

BigSandwich
  • 2,618
  • 2
  • 20
  • 26
  • 4
    Should be mentioned that having a project in more solutions will inevitably result in breaking other solutions when new dependencies are added or refactoring is done. Better approach is to have a project in only one solution and reference binaries in other solutions. NuGet is there for free and can be used to use projects as components from other solutions. – user3285954 Jun 03 '15 at 15:13
7

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.

Assaf Lavie
  • 63,560
  • 33
  • 139
  • 197
4

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.

Canavar
  • 46,286
  • 17
  • 83
  • 120
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.

BC.
  • 22,131
  • 12
  • 44
  • 62
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.

André Boonzaaijer
  • 551
  • 3
  • 11
1

When deciding what number of projects vs solutions do you need, you need to concider some questions:

  • logical layers of your application;
  • dependency between projects;
  • how projects are built;
  • who works with what projects;

Currently we have 1 solution with 70 projects. For our continous integration we created 5 msbuild projects, so CI does not build our development solution.

Previously, we had separate solution for presentation (web and related projects) layer in separate git repository. This solution was used by outsource and freelance web developers.

rustam
  • 136
  • 1
  • 4
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.

TheSmurf
  • 14,671
  • 2
  • 37
  • 47
1

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.

Brandon
  • 13,354
  • 15
  • 67
  • 108
1

I am working with a solution that has 405 projects currently. On a really fast machine this is doable, but only with current Visual Studio 2017 or 2012. Other versions crash frequently.

swissmawi
  • 21
  • 4
0

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.

GEOCHET
  • 20,623
  • 15
  • 71
  • 98
0

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.

Alan Mullett
  • 1,086
  • 12
  • 26