Menu
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?
890
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.
A solution is simply a container Visual Studio uses to organize one or more related projects. When you open a solution, Visual Studio automatically loads all the projects that the solution contains.
A solution folder is a container for one or more related projects. You can create many folders within a Visual Studio solution, including nested folders. They appear in the Solution Explorer as expandable and collapsible sections.
You could select a default startup project for the solution in the menu if you right click on it. This could also be done if you right click on the solution and go to the properties window where you could select a single or multiple startup projects.
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).
150
I mostly agree with @JaredPar but there a few things to consider when creating a massive solution.
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?
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.
5
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
