The project that we are currently working on had 80+ projects in our main solution. This took around 4 to 6 minutes to build depending on what kind of machine a developer was working on. We considered this time to be way too long. It means that for every single test it really eats away your FTEs….
It turned out that it is the number of projects in the solution that really hurts the buildtime.
So can we combine all our codefiles of all our projects by simply putting them all into just one project? Well to be honest we really took the effort and yes: it is possible, and yes, the buildtime is blazingly fast!
But still we did not choose this as a valid alternative. The problem of this is object hierarchy and clear separation of dependencies. If all classes can sudden call each other (because they are part of just one project) that would hurt the separation of dependencies bad time. That is: you want to maintain your overall object hierarchy.
However, we figured that we still had some projects that we could combine nevertheless: As every "Repository project" in our solution had its own unittest project, we simply combined all of these unittest projects into one global-unittest project. And that cut down the number of projects with about 12 projects and somehow shaved 40% off the time to build the entire solution.
We are thinking about another solution though.
We could try to setup a new (second) solution with a new fresh project and combine all sourcefiles into this one. Is that not the same as we already tried? Well yes but this second solution should simply incorporates all files using solution folders. That would keep the overall picture of dependencies clear, and we should not throw away our original (now 60+ project solution) at all.
We would keep the solution with the 60+ projects as our main solution that will be build on our buildserver. Than the responsibility of taking care of the project-separation will be done by the buildserver.
The second solution with just one project (which will build mucho faster) will than be the project where testing and debugging will be done by all developers. You have to take care of them looking at the buildserver though! If anything breaks it MUST be fixed.
Searching further on the internet, there might be even more ways to save buildtime. For example with incredibuild. Incredibuild uses all machines at your workplace as one big computing "grid". This sounds like the all famous chess-programs. Making use of idle processing power of machines in your company.
If we will need it, we will most certainly have a look at incredibuild.