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.