MSBuild 会因为 Windows 工作流而消亡吗? [英] Is MSBuild going to be dead because of Windows Workflow?

查看:16
本文介绍了MSBuild 会因为 Windows 工作流而消亡吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

MSBuild in TFS 2010 has been replaced by Windows Workflow 4.0. It means when you are creating a Build Definition, you won't have a TFSBuild.proj to edit instead you must edit a workflow to customize your build.

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

BTW am I correct if I say Microsoft is not supporting MSBuild in TFS 2010 and learning MSBuild as a TFS 2010 Team Build administrator doesn't worth?

另一个问题:微软是否会将 Visual Studio Projects 的语言从 MSBuild 替换为类似 Windows Workflow 的语言?

And another more question: is Microsoft going to replace Visual Studio Projects' language from MSBuild to something like Windows Workflow?

推荐答案

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

I'm the Program Manager for the build automation features of TFS, so I'd like to comment on this question. We haven't replaced MSBuild with Windows Workflow (WF). We still very much rely on MSBuild as the core build engine, which is its core competency. You'll find that there are lots of tasks that are still most easily and effectively automated with MSBuild.

我们引入 WF 作为在核心构建引擎(即我们包含在框中的构建过程模板中的 MSBuild)之上提供更高级别编排层的一种方式.它可以执行诸如在多台机器上分配流程并将流程与其他基于工作流的流程相关联的操作.

We introduced WF as a way of providing a higher level orchestration layer on top of the core build engine (which is MSBuild in the build process templates we include in the box). It makes it possible to do things like distribute a process across multiple machines and to tie the process into other workflow-based processes.

那么,什么时候应该用 MSBuild 自动化,什么时候应该用 WF 自动化?以下是我关于该主题的一般指导:

So, when should you automate with MSBuild and when should you automated with WF? Here's my general guidance on that subject:

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

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

When using MSBuild, remember that you can customize your project files directly (by unloading them and then editing them in Visual Studio), or you can create custom .targets files and import them into your individual projects. The latter approach is useful for functionality that's common to multiple projects to avoid maintaining multiple copies.

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

When using WF, remember that you can write code activities for low-level tasks but that you can also compose higher-level tasks using straight XAML. We're actually working on a version of the default build process template that shipped with TFS 2010 that gives you a simpler, less granular view of the overall process by using a set of composed XAML activities.

这篇关于MSBuild 会因为 Windows 工作流而消亡吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆