Optimising Visual Studio Build Times


At my current workplace we have 203 projects in a single tanged web of a solution. This unfortunately means the majority of projects need to be built for any of the services or sites to function, thus breaking down the solution is not a viable solution at the moment. So I took a look at reducing those build times, and here are my results:

Rebuilding your solution

Running a rebuild in visual studio 2008 takes… 

7:42 minutes

*Sigh* Let’s try the same thing in the Visual Studio 2008 Command prompt:

Msbuild.exe mysolution.sln /t:rebuild

2:39 minutes

*Wow* Let’s add some tweaks, first up is the multicore build tweak.

Msbuild.exe mysolution.sln /t:rebuild /m

1:25 minutes

*Pretty cool* There’s a strange bug in the normal command line which slows down execution of running programs. So let’s use a filelogger instead of a console logger.

Msbuild.exe mysolution.sln /t:rebuild /m /noconsolelogger /fl

Try it out and see if you get a decent benefits!

Building your solution

Running a normal build inside Visual Studio takes:

3:10 minutes

And using the command line:

Msbuild.exe mysolution.sln /t:build

27 Seconds

Now with the multicore tweak:

Msbuild.exe mysolution.sln /t:build /m

12 Seconds

So all in all not a bad way to manage a solution with 203 projects in it!

Happy deving…

If you can’t change the people, change the culture…


There’s a number of these quotes flying around:

If you can’t change the people, change the people.

If you can’t change the people, change yourself.

None of these are satisfactory, if we change the people, I feel like I would have failed in my approach to improve existing peoples approach in the workplace.

If I change myself, then its simply lowering my expectations of what it means to do your job to the best of your ability, not a good approach in my eyes.

So, piece by piece, perhaps we can change the culture…

Getting the Balance right

Part of changing the culture is getting the balance between change and comfort right. There is already a predetermined way of doing things which your colleagues are used to, and changing this fast makes people uncomfortable. There are a number of psychological tools we can employ to begin change:

  1. Present the benefits of the change clearly.
  2. Approach them in such a manner that at the end of the discussion it feels like their idea.
  3. Show the negative impacts of not making the move to gain sympathy.

If one of the above has been successful, then the idea has been planted in someone who isn’t yourself, you are recruiting an army.

Finding like minded people

There is a good change that you are not the only person who wishes a particular process or behaviour could be improved. Raise support through email lists and water cooler conversations. You may even strike up a conversation with someone who can make your life in initiating the change much easier.

Be relentless

Blasé workers and procrastinators and two major blockers you might find in your quest to apply improvements in the work place. You could bypass them and try a manager if they are in the way, but it would be better for everyone to involve them in the process. There can be a few strategies here:

  1. Include them in the need for change, and allow them to take credit for applying it. After all the main reason its being done is to make your work life better.
  2. Take over any work they would otherwise have to do themselves, including responsibility so all they need to do is sign and the work is done.

Don’t make any enemies

This one should go without saying, but its inevitable that there will be a strong character in your way, and the best way to get your changes pushed through is to swallow your pride and befriend them. You would be surprised how often an unpleasant veneer dissipates after minutes of friendly conversation.

Little by little

Your encounters with people, bit by bit has hopefully improved the workplace and the culture. Before you know it, you’ve changed the people as a by product.

Most of all, good luck and don’t give up!

Switching Visual Studio Environment Tools with Powershell and SlightlyPosher


Initially the SlightlyPosher environment configured the VS2008 tools as that was what I need on my project. Pascal was kind enough to send me a patch to use the VS2010 tools instead.

I thought it would be cool to satisfy both users, as not everyone has been lucky enough to switch to VS2010 yet.

In profile.ps1 by default the VS2010 tools are loaded.

Set-VsVars32 2010


If you would like to switch this, its as simple as calling:

Set-VsVars32 2008

Now you will have a VS2008 environment and MSBuild 3.5 at your fingertips.


The implementation for this is pretty straightforward…

#### Functions Used to Load VS Command Prompt #####
function Get-Batchfile ($file) {
    $cmd = "`"$file`" & set"
    cmd /c $cmd | Foreach-Object {
        $p, $v = $_.split('=')
        Set-Item -path env:$p -value $v

function Set-VsVars32($vsYear)
   switch ($vsYear)
        2008 {$vstools = $env:VS90COMNTOOLS}
        2010 {$vstools = $env:VS100COMNTOOLS }

   $batchFile = [System.IO.Path]::Combine($vstools, "vsvars32.bat") 
   Get-Batchfile -file $batchFile
   Write-Host -ForegroundColor 'Yellow' "VsVars has been loaded from: $batchFile"

The Get-BatchFile function is provided by many blogs describing how to use the Visual Studio tools with PowerShell. The Set-VsVars32 method takes the year as an argument, and loads the tools for that Visual Studio year.

Run update.bat to get these latest changes. Enjoy!

How would you like that developed, sir? Tactically or strategically?

Here’s a number of scenarios which I’ve seen played out repeatedly in different settings.  They all have a common root – see if you can spot it:

Business user: “Ever since you developers adopted agile you’re releases have been buggy!  Agile is rubbish!” Product Owner: “Great!  You’ve shown me exactly what I want!  Let’s launch tomorrow!”

Developer: “Oh no … it will take a least a month to get this ready for launch”
Product Owner: “That POC is spot on! Let’s start developing the next feature.”

Developer: “But it’s a POC … there’s a bunch of stuff we need to do to turn it into production-ready code.”
Project Manager: “The velocity of the team is far too low.  We should cut some of the useless unit testing stuff that you guys do.”


So what’s the common link?  Right … quality!  Or more specifically, different views around levels of quality.

Now in agile terms, quality is best represented in the definition of done.  This definition should codify exactly what you mean when you say “this story is done”, or “how long until it is done?”.  Scrum itself doesn’t provide any specific guidance around the definition of done, but says that it’s important the team agree this.

It’s important to note that the definition of done should not be specific to a given story.  So my story about bank transfers may have a number of acceptance criteria around how to debit and credit various accounts, but even if my code works I might not be done because I haven’t had my peer review yet.

With that all said, here is what I see is going wrong in the above scenarios:

The team have set their definition of done below the business user’s expectations (which are probably unstated) The team have set their definition of done below the product owner’s expectations - the product owner is expecting to include all release tasks The product owner doesn’t appreciate that there is a difference between POC code and code suitable for a long-term solution The project manager either doesn’t appreciate the benefits of unit tests, or thinks that the team have set their definition of done too high.


There are numerous good discussions and articles on the web about a definition of done (StackOverflow question, another question, an article, and another, and a HanselMinutes podcast), but I’d like to propose the idea that we should have some overall quality levels.  For instance, it doesn’t make sense to develop a strategic, long-term solution in the same way as a prototype.  So here’s what I propose as some overall quality levels:

  • Spike – Written to prove one single technical question.  Should never be extended unless that technical question needs to be explored further.
  • Prototype – Written as a quick-and-dirty demonstration of some functionality.  Can be used for on-going demonstrations, and so may need to be extended, but should never be deployed into production.
  • Tactical – Written to fulfil a specific, limited business requirement.  Life expectancy should be in the order of 2-3 years, after which it ought to be decommissioned and replaced.
  • Strategic – Written in response to on-going and continued business requirements.  Will be expected to evolve over time to meet changing business needs and emerging technologies.

And in terms of what I think these mean for a definition of done, here is my strawman (additional steps will most likely apply for a specific project, depending on the nature of the project):

Quality levels

So the next time you start a project, make up your own grid like this (or use this list, I don’t mind) and use it to have a detailed discussion with your product owner and scrum master.  It may surprise them to find that you are thinking about these issues, and their position on quality may well surprise you too!

Newer Posts Older Posts