Status... status and more status.  This is something new I'm trying, and I'd love to hear your feedback on the process.  As most people at Microsoft (heck probably anywhere), I have to send weekly status internally to my peers, the big cahunas and other interested parties.  My status covers MSBuild, and pretty much reports a pulse for the entire feature area.  What's Dev up to... what's QA up to... is the PM *still* slacking off (<-- don't answer that).   So if internal folks are generally interested in it... perhaps *you* are interested in it as well. 

So the question for you is:  Well are ya interested in it? 

I will attempt to post these on a regular basis, and through it, you can know what's up in MSBuild land.  Again we'll tweak the frequency and granularity of these as we go.  The more feedback you give... the better I'll be able to optimize this experience for you... Onto status then:

Internal Stuff

  • MSBuild has finalized plans to speak at the Microsoft Global Briefing (MGB) this year:
    • MSBuild will host 1 out of the 4 Instructor Led Hands on labs at MGB this year
    • MSBuild will host 1 breakout session at MGB this year
  • MSBuild checked in a few high profile fixes into Longhorn which were blocking the Avalon team
  • <Insert XBox studio name here> is now building XBox, XBox 2 and Windows games from a single MSBuild project file.  In their own words “I'm hoping the XBox Advanced Technology Group will get interested in MSBuild and offer tasks in addition to the VS integration they offer now“
  • New MSBuild last known good (LKG) was cut and released to our internal dogfooders
  • Internal wiki FAQ site has been created to better support our internal dogfooders. 
  • Internal wiki site has been created to better track Longhorn / MSBuild long term issues

External Stuff

  • Jeff ( has started blogging about MSBuild.  His blog is located at
  • Alex ( has started blogging about MSBuild.  His blog is located at (ahem... you are on it :) )
  • Christophe Nazarre's “Overview of MSBuild, Part 2: From the Task Author's Perspective“ was posted to MSDN
  • MSBuild made the front page of with Christophe Nazarre's second article
  • MSBuild had a good presence at TechEd in San Diego.  Final trip report can be found here
  • Stefan Bodewig had another great blog entry.  Full blog entry can be found here
  • We spoke with <insert large ISV name here> about integrating MSBuild in their overall build lifecycle.  In the words of the person who organized the meeting “You guys blew <insert ISV name here> away, and they are very excited about the capabilities of MSBuild“
  • MSBuild made an appearance at the VSIP dev lab and we gave them a quick overview of MSBuild.  4 distinct customer who shall remain nameless have engaged with us after the DevLab and we are currently talking with them about using MSBuild in their environments

Beta 1 Progress

  • MSBuild docs were reviewed and are ready for Beta 1
  • 596 out of 596 MSBuild nighlies1 are passing at 100%. 
  • 70 out of 70 MSBuild OGFs2 have been issued as “Meets Expectations“ for beta 1
  • 10 out of 10 MSBuild handshakes3 have been issued as “Meets Expectations“ for beta 1

Beta 2 Progress

  • The following Beta 2 design change requests (DCRs) have gone through VSCore management approval and are now on our list:
    • Improve whitespace preservation in MSBuild project files
    • Allow OutputPath / OutDir / IntermediaryOutputPath properties to support both full-path as well as relative or UNC paths
    • Fully support project to project (P2P) references that have manifests associated with them.  This is required for RegFree COM support in ClickOnce applications
    • Expose functionality that allows Visual Studio flavored4 projects to execute any arbitrary target within MSBuild
  • Our new intern, Jeff Vaughan (, started working on MSBuild.  He'll be with us until the end of August.  WELCOME Jeff!


  • MSBuild perf scenarios are ready to run as Pri1 performance tests in the pef lab.  Our current P1 scenarios consist of:
    • Small - Individual / Small feature team (eg MSBuild itself with ~10 leaf node projects)
    • Medium - Entire feature team (eg Visual Studio solution and project systems ~50 leaf node projects)
    • Large - Entire product unit (eg Visual Basic ~500 leaf nodes)
    • X-Large - Entire division at Microsoft (eg All of Visual Studio ~4500 leaf nodes)
  • Work has started to integrate MSTV Server (~75 leaf projects) as one of our performance scenarios.  Based on this work we've been able to:
    • Isolate performance issues around our Resolve Assembly Reference (RAR) task. 
    • Improved overall load time by 10% (5 seconds).
  • Recent perf numbers on MSBuild compared to Build.exe / nmake:
    • Build.exe / nmake5 building the MSBuild tree (1 CPU) - 55.25 seconds
    • MSBuild.exe building the MSBuild tree (1 CPU) - 36.60 seconds!!
  • MSBuild peak size reduced from 55 megs to 15 megs.  Total allocations (ie GC pressure) went from 280 megs to 170 megs.  This ginormous improvement is mostly due to:
    • MSBuild now cache's imported project xml to prevent re-parsing
    • MSBuild now uses case insensitive hash keys to prevent storing upper case copy of all MSBuild property and item keys

So that concludes the status... you are now UP TO DATE <-- in msbuild speak that means you will be skipped next time we build you :) (ok dorky joke but I couldn't resist)

Useful?  More of it? Less of it?  Inquiring minds want to know :)

Nightlies - we have ~2100 distinct automated tests for MSBuild.  Some more important than others.  Nightlies are some of the most fundamental tests we run.  As their name implies we run these on a daily (ahem nightly) basis and they are meant to test critical customer scenarios.  Breaking or regressing a nightly is really bad.  Nightlies are a great indicator of our overall product stability. 
OGFs - Overall Good Feeling or Overall Goodness Factor (I can never remember).  A few times per milestone our awesome QA organization tests end-to-end scenarios (both manually as well as automated).  Based on the end-to-end experience they issue an OGF for the scenario.  The collection of these OGFs isused as an indicator of our overall product quality. Example of an OGF for MSBuild would be “Logger Initialization and Shutdown“
Handshakes - A collection of cohesive OGFs bubbles up into a Handshake.  If all OGFs within a handshake pass then a passing handshake is issued.  If at least one OGF does not meet expectations the entire Handshake fails.  An example of an MSBuild handshake would be “MSBuild Logging Handshake“ which would contain all MSBuild OGFs.
4 Flavored Project - these are project that build ontop of our core VB/C#/J# project systems and tend to optimize for a given technology.  Examples of these “flavored“ projects are the Smart Devices, VSTO or Yukon projects. 
Note - This is build.exe as we run it internally within our build labs.  Number may vary if you hand author your makefiles from scratch. 

_*_*_*_ Update: Swapped the 4th and 5th footnotes.  Thanks goes to David Cumps for pointing that out. _*_*_*_