Visual Studio: Single solution or many solutions?

Question

Right now this legacy code is multiple projects, each in it's own solution. Each project references another project by it's compiled dll. to get the main project running you have to go through 10+ individual builds in the correct order.

I'm trying to explain how moving all projects under a single solution is a good idea to fix all of these issues. How can I explain to the other devs that this is a better idea? I can't see how it isn't a better way to go, but is it or am I wrong?

Answer 1

You are correct and I'd explain it to the other developer in terms of benefits

The simplest argument for me is building 1 time is much faster than building 1 solution 10 times. Loading up every different solution individually is tedious and time consuming. Visual Studio is about making your life better, loading solutions 10 different times just makes your life worse.

Additionally putting all the projects in one solution means you get live support for many features like IntelliSense, Refactoring, Find All References, etc ... Having live project references produces a much better experience than going through DLLs. Refactoring is one feature that is severely limited in it's usefulness when going through DLLs.

If they are worried about the cost of rebuilding the world constantly when iterating on a root project then the best approach is to create a new build configuration which only builds the root projects. Solutions support multiple build configurations and switching between them is very fast (much faster than switching between solutions).

Answer 2

I mostly agree with @JaredPar but there a few things to consider when creating a massive solution.

1. Performance - Yes building may be less of a tedious task but Rebuilding a bunch of "core" projects that change infrequently wastes cycles, As Jared said you can mitigate this with build configs. Also Visual Studio tends to be a resource hog and the problem, in my experience, is exacerbated as your solution grows. If you have core pieces that change infrequently then what is the benefit of loading them all the time?

2. Refactoring - This is a double edged sword IMO. Yes it is easier to do renames, moves, replaces etc.. when all the code is loaded. However, since it is easier you can also run into situations where people will add references to projects and move things across project boundaries when, from a architectural perspective, that isn't the correct approach. Because VS makes it so easy to do you have to watch out for people blindly refactoring and breaking architectural guidelines

P&P has published some guidance on this topic: http://msdn.microsoft.com/en-us/library/bb668953.aspx

It is a little dated and talks about TFS specifically but some of the main concepts are still valuable to consider.