TFS 2010中的MSBuild已被Windows Workflow 4.0所取代.这意味着当您创建构建定义时,您将不会有一个TFSBuild.proj进行编辑,而是必须编辑工作流来自定义构建.
如果我说Microsoft在TFS 2010中不支持MSBuild,并学习MSBuild作为TFS 2010团队,建议管理员不值得吗？
还有另一个问题：微软是否会将Visual Studio Projects的语言从MSBuild替换为Windows Workflow？
我是TFS的构建自动化功能的程序经理,所以我想对这个问题发表评论.我们没有用Windows Workflow(WF)取代MSBuild.我们仍然非常依赖MSBuild作为核心构建引擎,这是其核心竞争力.你会发现,有很多任务仍然是最容易和有效的自动化MSBuild.
我们引入WF作为在核心构建引擎(在框中包含的构建过程模板中为MSBuild)提供更高级别编排层的方式.它使得可以执行诸如在多个机器之间分发流程并将流程绑定到其他基于工作流的流程.
那么,什么时候应该使用MSBuild进行自动化,何时应该使用WF进行自动化？这是我关于这个问题的一般指导：
>如果任务需要了解具体的构建输入或输出,请使用MSBuild
>如果任务是您在Visual Studio中构建时需要执行的任务,请使用MSBuild
>如果任务是您在构建服务器上构建时只需要执行的任务,请使用WF,除非需要知道特定构建输入/输出
当使用MSBuild时,请记住,您可以直接自定义项目文件(通过卸载它们,然后在Visual Studio中进行编辑),也可以创建自定义的.targets文件并将其导入到各个项目中.后一种方法对于多个项目通用的功能来避免维护多个副本很有用.
当使用WF时,您可以为低级任务编写代码活动,但也可以使用直接XAML编写更高级别的任务.我们实际上正在使用TFS 2010附带的默认构建过程模板的版本,通过使用一组组合的XAML活动,可以更简单,更精细地查看整个流程.
