Windows Workflow vs. MSBuild in TFS 2010

I often hear people asking if Windows Workflow replaces MSBuild in TFS 2010, so I wanted to take a moment to comment on this question.

We haven’t replaced MSBuild with Windows Workflow (WF). We still very much rely on MSBuild as the core build engine, which is it’s core competency. You’ll find that there are lots of tasks that are still most easily and effectively automated with MSBuild. In fact, for the next release of Visual Studio, we’re working with the MSBuild team to replace solution (.sln) files with MSBuild project files.

We introduced WF as a way of providing a higher level orchestration layer on top of the core build engine (which is MSBuild in the build process templates we include in the box). It makes it possible to do things like distribute a process across multiple machines and to tie the process into other workflow-based processes.

So, when should you automate with MSBuild and when should you automated with WF? Here’s my general guidance on that subject:

  • If the task requires knowledge of specific build inputs or outputs, use MSBuild
  • If the task is something you need to happen when you build in Visual Studio, use MSBuild
  • If the task is something you only need to happen when you build on the build server, use WF unless it requires knowledge of specifi build inputs/outputs

When using MSBuild, remember that you can customize your project files directly (by unloading them and then editing them in Visual Studio), or you can create custom .targets files and import them into your individual projects. The latter approach is useful for functionality that’s common to multiple projects to avoid maintaining multiple copies.

When using WF, remember that you can write code activities for low-level tasks but that you can also compose higher-level tasks using straight XAML. We’re actually working on a version of the default build process template that shipped with TFS 2010 that gives you a simpler, less granular view of the overall process by using a set of composed XAML activities.

Comments (1)

  1. Keith Kyle says:

    Great news.   In reference to the “composed XAML activities" you mentioned, I am wondering if any of those activities would happen in include things such as :

    • Web Assembly Pre-compilation – Execution of aspnet_compiler against our solution file

    • Web Assembly Merging  – Execution of aspnet_merge.exe

    • Installation Media Packaging – while we have not automated this yet, it is something we would like to be able to do with our installation tools.

    • Build Drop Output organization – since we archive this information at the release point, we customize the output folders and files in a specific way.

    • Automated Deployment of Nightly Build

          -DB Installation – call to our scripts via the <Exec /> task

          -Web Site – use of psexec.exe tool via the <Exec /> task

    • Build Verification Activities

           -Inspection of our database build log installed on our nightly application server for errors

           -NUnit Test Execution

           -Inspection of our DB and NUnit test xml output files to build customized email with our nightly BVT results summary.

    In the past and currently, we’ve utilized a series of <Exec /> within our TFSBuild.proj file to accomplish these types of things.  Ideally, we would like to use the DefaultTemplate.xaml to take advantage of the WF improvements.  So far, we’ve been using the UpgradeTemplate.xaml.