tfs - MSBuild 会因为 Windows 工作流而消亡吗？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




9年前关闭。




TFS 2010 中的 MSBuild 已被 Windows Workflow 4.0 取代。这意味着当您创建构建定义时，您将无法编辑 TFSBuild.proj，而必须编辑工作流来自定义您的构建。

顺便说一句，如果我说 Microsoft 不支持 TFS 2010 中的 MSBuild 并且作为 TFS 2010 Team Build 管理员学习 MSBuild 不值得，我是否正确？

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

Answer 1

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

我们引入了 WF 作为在核心构建引擎(这是我们包含在框中的构建过程模板中的 MSBuild)之上提供更高级别编排层的一种方式。它可以做一些事情，比如在多台机器上分配一个流程，并将该流程与其他基于工作流的流程联系起来。

那么，什么时候应该用 MSBuild 自动化，什么时候应该用 WF 自动化？这是我对该主题的一般指导:

如果任务需要特定构建输入或输出的知识，请使用 MSBuild

如果任务是您在 Visual Studio 中构建时需要发生的事情，请使用 MSBuild

如果任务是您只需要在构建服务器上构建时发生的事情，请使用 WF，除非它需要特定构建输入/输出的知识

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

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