Tfs MSBuild是否会因为Windows工作流而失效？

TFS 2010中的MSBuild已被Windows Workflow 4.0替换。这意味着，当您创建生成定义时，您将没有要编辑的TFSBuild.proj，而必须编辑工作流以自定义生成

顺便说一句，如果我说微软在TFS 2010中不支持MSBuild，并且作为TFS 2010团队构建管理员学习MSBuild是不值得的，那么我是对的吗

---

还有一个问题：微软是否打算将Visual Studio项目的语言从MSBuild替换为类似Windows Workflow的语言？

我不认为MSBuild将被Workflow 4.0所取代，而是认为这两种技术将相互补充，并将共存。在MSBuild中会有一些比工作流更容易执行的任务类别。因此，人们将对某些集合使用MSBuild，而对另一个集合使用工作流。因此，在某种意义上，它将是工作流和MSBuild的混合体

---

顺便说一下，TFS2010确实使用its支持MSBuild，我认为工作流不能取代VisualStudio项目语言中的MSBuild

我是TFS构建自动化功能的项目经理，所以我想对这个问题发表评论。我们尚未将MSBuild替换为Windows工作流（WF）。我们仍然非常依赖MSBuild作为核心构建引擎，这是它的核心竞争力。您会发现，使用MSBuild仍然可以最轻松有效地自动化许多任务

我们引入WF是为了在核心构建引擎（我们在框中包含的构建过程模板中是MSBuild）的顶部提供更高级别的编排层。它可以在多台机器上分发流程，并将流程绑定到其他基于工作流的流程中

那么，什么时候应该使用MSBuild进行自动化，什么时候应该使用WF进行自动化？以下是我对该主题的一般指导：

• 如果任务需要了解特定的生成输入或输出，请使用MSBuild
• 如果任务是在Visual Studio中生成时需要执行的，请使用MSBuild
• 如果任务只需要在构建服务器上构建时执行，则使用WF，除非它需要特定构建输入/输出的知识

使用MSBuild时，请记住，您可以直接自定义项目文件（通过卸载它们，然后在Visual Studio中编辑它们），也可以创建自定义.targets文件并将它们导入到各个项目中。后一种方法对于多个项目通用的功能非常有用，以避免维护多个副本

---

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

工作流构建现在是遗留的：）是的，它们确实是。我希望当我们迁移到WF时，Node或.NET Core是一个可行的选择。