What's the largest Visual Studio solution you've ever seen?
-
Dave Polaschek (he/him)replied to Dave Heinemann 🇦🇺 last edited by
@dHeinemann Umm, four apps, two libraries, contained over 100 sub-projects. When I retired in 2019, a clean build from nothing wouldn’t finish (at all, because of bad dependencies on some libraries we didn’t own). If you did a command-line build first, then a clean, a new build (of just one app target) took the better part of a working day. Was a C/C++ app, with bits of JavaScript, ActionScript, and some C# mixed in to get at things that only existed in dot-net.
-
Jake Carpenterreplied to Dave Heinemann 🇦🇺 last edited by
@dHeinemann one at my work has over 100. Some absolutely idiotic consultant told them to split Sitecore features by project. They’re all deployed at the same time to the same place.
There’s rarely a good reason to split into multiple projects unless they’re going to deploy independently. When that is the case, there’s usually an explosion of projects to support the separation. There’s no harm in that, but there’s overhead for the developer to find things that should be avoided if possible.
-
Tom Robertsreplied to Dave Heinemann 🇦🇺 last edited by
@dHeinemann It doesn't take too long. Maybe less than 2 minutes.
It's a scientific application and when it was designed in the 00s, they made the decision that you could extend it by adding a DLL with your own scientific module.
So to support that idea, lots of the core modules are set up as their own .csproj containing a discrete piece of functionality.
So lots of projects, but many aren't that big.
We have another two solutions that build on the output of the first, with another 50 or so projects each.
-
@dHeinemann I just checked... 41 seconds!
-
Dave Heinemann 🇦🇺replied to Dave Polaschek (he/him) last edited by
@davepolaschek Wow, that's a janky build process.
Our 100-project solution takes about 5 minutes to compile from scratch. Not bad.
-
Dave Heinemann 🇦🇺replied to Jake Carpenter last edited by
@jakecarpenter Yeah, there's definitely a developer overhead.
Our libraries basically represent the boundaries of major namespaces, and there are /a lot/ of dependencies across them all. I reckon we could consolidate and merge a lot of them togwther.
-
Dave Heinemann 🇦🇺replied to Tom Roberts last edited by
@troberts That's pretty fast!
Our codebase is pretty big. I haven't measured it, but it'd at least be several hundred thousand lines of C#.
-
Simon Croppreplied to Dave Heinemann 🇦🇺 last edited by
@dHeinemann have u considered combining the test projects. given the dont need to be deployed separately, it usually results in much IDE perf and build times if u combine as many as possible
-
Dave Heinemann 🇦🇺replied to Simon Cropp last edited by
@simoncropp That's a good idea. They definitely have a performance impact. At the moment, I unload all the unit test projects until I actually need them.
-
Simon Croppreplied to Dave Heinemann 🇦🇺 last edited by
@dHeinemann solution filter files are also useful. so u can work on a subset of projects
-
Dave Heinemann 🇦🇺replied to Simon Cropp last edited by
@simoncropp Thanks, this is exactly what I need for the time being! It's so rare that I need to build /literally everything/ in this repo, and manually loading and unloading projects is tedious.