TFS 2010: Is MSBuild going to be dead because of Windows Workflow?

Question

MSBuild in TFS 2010 has been replaced by Windows Workflow 4.0. It means when you are creating a Build Definition, you won't have a TFSBuild.proj to edit instead you must edit a workflow to customize your build.

BTW am I correct if I say Microsoft is not supporting MSBuild in TFS 2010 and learning MSBuild as a TFS 2010 Team Build administrator doesn't worth?

And another more question: Is microsoft going to replace Visual Studio Projects' language from MSBuild to something like Windows Workflow?

Many Thanks

Answer 1

I dont think that MSBuild will be replaced by workflow 4.0, rather I think both of these technologies will augment each other and will exist together. There will be some category of tasks which are easier to do in MSBuild than workflow. So people are going to use MSBuild for some set and workflow for other set. So in some sense it will be mix of both workflow and MSBuild.

By the way Tfs 2010 do support MSBuild using its upgrade template. and I dont think workflow can replace MSBuild in Visual Studio Projects language.

Answer 2

I'm the Program Manager for the build automation features of TFS, so I'd like 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.