MSBuild va-t-il être mort à cause de Windows Workflow?

Question

MSBuild dans TFS 2010 a été remplacé par Windows Workflow 4.0. Cela signifie que lorsque vous créez une définition de construction, vous n'avez pas besoin d'éditer TFSBuild.proj à la place, vous devez modifier un flux de travail pour personnaliser votre construction.

Ai-je raison de dire que Microsoft ne prend pas en charge MSBuild dans TFS 2010 et que l'apprentissage de MSBuild en tant qu'administrateur TFS 2010 Team Build ne vaut pas?

Et encore une autre question: est-ce que Microsoft va remplacer le langage Visual Studio Projects de MSBuild par quelque chose comme Windows Workflow?

Answer 1

Je suis le gestionnaire de programme pour les fonctionnalités d'automatisation de la construction de TFS, alors j'aimerais commenter cette question. Nous n'avons pas remplacé MSBuild avec Windows Workflow (WF). Nous comptons encore beaucoup sur MSBuild en tant que moteur de construction de base, qui est sa compétence de base. Vous constaterez qu'il y a beaucoup de tâches qui sont encore plus facilement et efficacement automatisées avec MSBuild.

Nous avons présenté WF comme un moyen de fournir une couche d'orchestration de niveau supérieur au moteur de construction principal (MSBuild dans les modèles de processus de construction que nous incluons dans la boîte). Il permet de répartir un processus sur plusieurs machines et de lier le processus à d'autres processus basés sur le flux de travail.

Alors, quand devriez-vous automatiser avec MSBuild et quand devriez-vous automatiser avec WF? Voici mon orientation générale sur ce sujet:

• Si la tâche nécessite la connaissance des entrées ou des sorties de construction spécifiques, utilisez MSBuild
• Si la tâche est quelque chose que vous devez arriver lorsque vous créez dans Visual Studio, utilisez MSBuild
• Si la tâche est quelque chose que vous avez seulement besoin de se produire lorsque vous créez sur le serveur de build, utilisez WF à moins qu'il ne nécessite la connaissance des entrées/sorties de construction spécifiques

lorsque vous utilisez MSBuild, rappelez-vous que vous pouvez personnaliser vos fichiers de projet directement (en les déchargeant et t si vous les éditez dans Visual Studio), ou vous pouvez créer des fichiers .targets personnalisés et les importer dans vos projets individuels. Cette dernière approche est utile pour les fonctionnalités communes à plusieurs projets afin d'éviter le maintien de plusieurs copies. Lorsque vous utilisez WF, n'oubliez pas que vous pouvez écrire des activités de code pour les tâches de bas niveau, mais que vous pouvez également composer des tâches de niveau supérieur à l'aide de XAML direct. Nous travaillons actuellement sur une version du modèle de processus de génération par défaut fourni avec TFS 2010 qui vous donne une vue plus simple et moins granulaire du processus global en utilisant un ensemble d'activités XAML composées.

Answer 2

Je ne pense pas que MSBuild sera remplacé par workflow 4.0, mais je pense que ces deux technologies vont se compléter et existeront ensemble. Il y aura une catégorie de tâches qui sont plus faciles à faire dans MSBuild que le workflow. Donc, les gens vont utiliser MSBuild pour un ensemble et un flux de travail pour un autre ensemble. Donc, dans un certain sens, ce sera à la fois un flux de travail et MSBuild. Par ailleurs, Tfs 2010 prend en charge MSBuild en utilisant ses upgrade template. et je ne pense pas que workflow puisse remplacer MSBuild dans le langage des projets Visual Studio.