visual-studiosolutionprojects-and-solutions

Reputation: 1271

Recommended number of projects in Visual Studio Solution

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)

Upvotes: 23

Answers (13)

Dennis

Reputation: 11

2023 Update - We have a solution with over 300 projects and with VS2022 it works just fine on a modest machine. We tried the split route and the overhead of Nugets and pain in refactoring was just not worth it. We do have some smaller solutions with subsets of the projects for easier working but maintain a master solution to ensure things build.

Upvotes: 1

swissmawi

Reputation: 59

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.

Upvotes: 2

rustam

Reputation: 154

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.

Upvotes: 2

BigSandwich

Reputation: 2816

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.

Upvotes: 19

Nader Shirazie

Reputation: 10776

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

Upvotes: 30

Alan Mullett

Reputation: 1116

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.

Upvotes: 0

Canavar

Reputation: 48108

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.

Upvotes: 4

GEOCHET

Reputation: 21323

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.

Upvotes: 0

Assaf Lavie

Reputation: 76153

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.

Upvotes: 9

Brandon

Reputation: 14196

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.

Upvotes: 1

BC.

Reputation: 24978

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.

Upvotes: 4

André Boonzaaijer

Reputation: 846

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.

Upvotes: 2

TheSmurf

Reputation: 15588

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.

Upvotes: 1

Recommended number of projects in Visual Studio Solution

Answers (13)

Related Questions