MSBuild vs. Workflow

We have been using MSBuild for a few years successfully in our company. We have a very custom .proj build file for every Build specification (Release, Debug, etc.) which include many operations as:

• Obfuscation
• Packing
• Copying outputs
• Compressing
• 开发者_C百科Etc

Since Microsoft included a new feature in TFS2010 to make builds using Windows Workflow Foundation, we are thinking to change to it. As Jim Lab (Program Manager for Team Foundation Server) said in an article, here's his general guidance on when should be use them:

• 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 specific build inputs/outputs

I am not still quite sure about it and I would like to know your own experience, positive things, drawbacks, etc. Your opinion would be more valuable if you have modified the DefaultTemplate.xaml to perform your own operations.

We've made the transition from MSBuild to Workflow migrating from TFS2008 to TFS2010. Some experiences:

1. The MSBuild specifications work fine in Workflow when you use the UpgradeTemplate.xaml. This allows for a relaxed migration of TFS2008 to TFS2010
2. MSBuild gives more control to development teams on how they want their builds to run. Members can easily modify the specifications themselves and check in changes. Workflow is more of a BuildMaster thing.
3. MSBuild changes can be quickly made. Workflow changes are a bit more troublesome. Sometimes, quick changes are good, but also deviate development team from a governd line of doing things.
4. Workflow seperates the process template from the data used to drive a specific build. These templates are easilier reusable.

Personal overall impression: use MSBuild for smaller development team driven building. Use Workflow for mature product manufacturing lines.