Build Times

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.”


Go to jail 1

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. Break up into many solutions to keep build times lean. You should already have these kinds of boundaries in your system.

If you corporate anti-virus takes you from 20-30 seconds to 2-3 minutes dear god find some way to get it off those machines even if it means living on a segregated network.

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!)


  1. Posted February 27, 2012 at 7:55 am | Permalink | Reply

    Actually, there is one shared lib in my source code that prevents me from having nice separate solutions. You motivated me to finally get rid of it and be happy

  2. @markjbryant
    Posted February 27, 2012 at 9:10 am | Permalink | Reply

    I believe if you are using TFS then a single solution is the recommended approach. Another reason not to use TFS.

  3. Posted February 27, 2012 at 10:31 am | Permalink | Reply

    @szymon, if your shared lib contains frequently used utilities, packages it and use something like nuget or openwrap. Somehow, we need libraries for things like serialization, storage etc anyway.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: