Build Times | Greg Young
Was answering some questions about Mighty Moose today and figured I would just drop a quick note here about the topic.
“Mighty Moose does not work very well on my project as it takes 3-5 minutes for things to show up as my build takes that long.”
If your build is taking this long you have some very serious problems on your team and with your source base. A build being used by developers to actively develop that takes this long should be your first priority to fix. There is no excuse for having a build that takes this long under any circumstances.
Note I make a difference between a build developers use to actively develop and a build on a CI server etc.
To have a build taking this long makes it impossible for developers to develop. How many times per day do you build? You are losing n MINUTES per build? Extrapolate this to a team of 7.
Oddly I have found many people doing this on purpose! The rational is using refactoring tools like reshaper and coderush. They want refactoring support across the whole codebase. Ask yourself, do you really want refactoring support across layer and tier boundaries? This sounds scary.
Another reason I commonly heart is for debugging support (that way you can step into everything). You can do this without creating one massive solution for everything, a bit of brush up on the debugging tools/support in Visual Studio can show you how to do this.
Do not create solutions that take minutes to build. Solutions are meant to be workspaces to code in, not how you produce your production build etc.
Mighty Moose resolution: Won’t fix. If you are in this scenario though the cascading builds in Mighty Moose though sometimes non-trivial to setup might help alleviate some of your pain as they only build projects that need to be built (and if your build is fast, they can make it even faster!)