由于Windows工作流程，MSBuild会死？

Question

TFS 2010中的MSBuild已被Windows Workflow 4.0所取代。这意味着当您创建构建定义时，您将不需要编辑TFSBuild.proj，而是编辑工作流以自定义构建。

顺便说一句，如果我说微软不支持MSBuild在TFS 2010和学习MSBuild作为TFS 2010团队建设管理员不值得？

还有一个问题：微软是否会将Visual Studio Projects的语言从MSBuild替换为Windows Workflow之类的东西？

Answer 1

我是TFS构建自动化功能的程序管理器，所以我想对此问题发表评论。我们还没有用Windows Workflow（WF）替换MSBuild。我们仍然非常依赖MSBuild作为核心构建引擎，这是它的核心竞争力。你会发现有很多任务仍然是最容易和有效地使用MSBuild实现的。

我们引入了WF作为在核心构建引擎（这是我们在框中包含的构建过程模板中的MSBuild）之上提供更高级别的编排层的方式。它可以执行诸如在多台机器上分配进程并将进程与其他基于工作流程的进程相关联的功能。

那么，什么时候应该使用MSBuild自动化，何时使用WF自动化呢？下面是关于这个问题我的一般性指导：如果任务需要的特定生成的输入或输出知识

• ，使用的MSBuild
• 如果任务需要发生，当你在Visual Studio中建立，使用的MSBuild
东西
• 如果任务是，你只需要在生成生成服务器上发生的事情，使用WF使用的MSBuild，记住，你可以定制你的项目文件，除非它需要特定的构建输入/输出

的知识直接（通过卸载它们和t在Visual Studio中编辑它们），或者您可以创建自定义.targets文件并将它们导入到您的单个项目中。后一种方法对于多个项目通用的功能非常有用，以避免维护多个副本。

使用WF时，请记住您可以编写低级别任务的代码活动，但也可以使用直接XAML编写更高级别的任务。实际上，我们正在使用TFS 2010附带的默认构建过程模板的一个版本，通过使用一组组合的XAML活动，为您提供更简单，粒度更小的整个过程视图。

Answer 2

我不认为MSBuild将被工作流程4.0所取代，相反我认为这两种技术都会互相补充并且会一起存在。将会有一些类别的任务在MSBuild中比在工作流程中更容易完成。因此，人们将使用MSBuild进行其他设置的一些设置和工作流程。所以从某种意义上说，它将是工作流和MSBuild的混合体。

顺便说一下，Tfs 2010支持MSBuild使用其upgrade template.，我不认为工作流可以替换Visual Studio项目语言中的MSBuild。