¿MSBuild va a estar muerto debido a Windows Workflow?

Question

MSBuild en TFS 2010 ha sido reemplazado por Windows Workflow 4.0. Significa que cuando está creando una Definición de compilación, no tendrá un TFSBuild.proj para editar, sino que debe editar un flujo de trabajo para personalizar su compilación.

BTW ¿Estoy correcto si digo que Microsoft no admite MSBuild en TFS 2010 y que aprender MSBuild como administrador de Team Build TFS 2010 no vale?

Y otra pregunta más: ¿reemplazará Microsoft el lenguaje de Visual Studio Projects de MSBuild a algo así como Windows Workflow?

Answer 1

Soy el Administrador de programas para las funciones de automatización de compilación de TFS, por lo que me gustaría comentar esta cuestión. No hemos reemplazado MSBuild con Windows Workflow (WF). Todavía confiamos mucho en MSBuild como motor de compilación central, que es su competencia principal. Descubrirá que hay muchas tareas que aún se automatizan de manera más fácil y efectiva con MSBuild.

Presentamos WF como una forma de proporcionar una capa de orquestación de nivel superior sobre el motor de compilación central (que es MSBuild en las plantillas de proceso de compilación que incluimos en el recuadro). Hace posible hacer cosas como distribuir un proceso en varias máquinas y vincular el proceso a otros procesos basados ​​en flujo de trabajo.

Entonces, ¿cuándo debería automatizar con MSBuild y cuándo debería automatizarse con WF? Aquí está mi guía general sobre ese tema:

• Si la tarea requiere el conocimiento de las entradas o salidas de generación específicos, utilizar MSBuild
• Si la tarea es algo que tiene que suceder cuando se genera en Visual Studio, utilizar MSBuild
• Si la tarea es algo que sólo se necesita que suceda cuando se genera en el servidor de compilación, utilice WF menos que requiere el conocimiento de los insumos de construcción/salidas específicas

al utilizar MSBuild, recuerde que usted puede personalizar sus archivos de proyecto directamente (descargándolos yt uando los edite en Visual Studio), o puede crear archivos .targets personalizados e importarlos a sus proyectos individuales. El último enfoque es útil para la funcionalidad que es común a múltiples proyectos para evitar el mantenimiento de copias múltiples.

Al usar WF, recuerde que puede escribir actividades de código para tareas de bajo nivel pero que también puede componer tareas de alto nivel utilizando XAML directo. En realidad, estamos trabajando en una versión de la plantilla de proceso de compilación predeterminada incluida con TFS 2010 que le brinda una vista más simple y menos granular del proceso general mediante el uso de un conjunto de actividades XAML compuestas.

Answer 2

No creo que MSBuild sea reemplazado por workflow 4.0, más bien creo que ambas tecnologías se aumentarán mutuamente y existirán juntas. Habrá algunas categorías de tareas que son más fáciles de hacer en MSBuild que el flujo de trabajo. Entonces, las personas van a usar MSBuild para un conjunto y flujo de trabajo para otro conjunto. Entonces, en cierto sentido, será una mezcla de flujo de trabajo y MSBuild.

Por cierto, Tfs 2010 admite MSBuild con su upgrade template. y no creo que el flujo de trabajo pueda reemplazar a MSBuild en el lenguaje de proyectos de Visual Studio.