Avantages de l'utilisation de MSBuild ou de NAnt par rapport à l'exécution de DevEnv.exe à partir de la ligne de commande

Question

Quelqu'un peut-il expliquer les avantages qu'il y a à utiliser un outil tel que MSBuild (ou NAnt) pour créer une collection de projets par rapport à l'exécution de DevEnv.exe à partir de la ligne de commande?

Un collègue avec lequel j'avais travaillé dans le passé m'avait expliqué que DevEnv.exe (du moins avec les anciennes versions de Visual Studio) était beaucoup plus lent que les autres techniques, mais je n'ai lu aucune preuve de cela ou si est devenu un sujet de discussion maintenant que depuis 2005, Visual Studio utilise MSBuild sous le capot.

Je connais l'un des avantages de l'utilisation de MSBuild qui vous permet de construire vos projets sans nécessiter l'installation de Visual Studio sur les machines de génération, mais je ne savais pas s'il en existait d'autres.

Answer 1

Une des raisons est qu’il est bien plus complexe de concevoir un produit que de le compiler. Des tâches telles que la création d'installations, la mise à jour de numéros de version, la création de comptes bloqués, la distribution des packages finaux, etc. peuvent être beaucoup plus simples en raison de ce que ces outils (et leurs extensions) fournissent.

Bien que vous puissiez faire tout cela avec des scripts normaux, l'utilisation de NAnt ou de MSBuild vous donne un cadre solide pour faire tout cela. La communauté prend beaucoup en charge les deux, y compris des tâches supplémentaires pouvant être téléchargées (telles que le projet de tâches de la communauté MSBuild . ). De plus, ils sont pris en charge par de nombreux produits tiers et à source ouverte.

Si vous êtes seulement intéressé par la compilation (et non par le processus de construction complet), vous constaterez peut-être qu'un avantage unique de MSBuild en termes d'économie est le prise en charge de la construction avec plusieurs processeurs .

Answer 2

La réponse évidente de mon équipe est que Visual Studio n’est pas installé sur tous les téléviseurs , en particulier Visual Studio n’est pas installé sur nos serveurs build / CI.

Answer 3

La principale raison d'utiliser un outil de génération externe, tel que NAnt ou MsBuild, est la possibilité d'automatiser votre processus de génération et de fournir ainsi des informations en continu sur l'état de votre système. En outre, ils peuvent être utilisés pour des tas de choses en plus d'un "pur" & construire et c’est là que vous commencez vraiment à en tirer parti, c’est une chose extrêmement précieuse de pouvoir construire et tester votre application avec une seule commande.

Vous pouvez également commencer à ajouter des éléments tels que la collecte de mesures, l’emballage des fichiers binaires de publication et toutes sortes d’autres choses intéressantes comme celle-là.

Answer 4

En ce qui concerne C #, devenv.exe 2005 exécute le compilateur in-proc, ce qui peut entraîner des exceptions de mémoire insuffisante pour les solutions importantes. Msbuild a recours au processus csc.exe pour chaque projet. Les projets qui ne compilent pas avec devenv / build fonctionnent correctement avec msbuild. J'espère que vous aimez cette raison.

Answer 5

Nous essayons de passer de DevEnv à un outil (Visual Build Pro) qui utilise MsBuild sous le capot et nous avons obtenu une "Référence requise pour l'assembly 'System.Drawing ...". erreur pour un projet qui n'en a pas besoin et qui fonctionne correctement dans Visual Studio.

Answer 6

Nous avons un grand système composé de C #, de C ++ managé et de vieux assemblages / dll C ++ non gérés. Il existe un code C ++ qui dépend du code C ++ géré qui dépend du code C # qui dépend du code C ++ géré qui dépend du vieux code C ++ (whew!). Lors de la configuration de notre environnement de construction automatisé il y a quelques années, nous avons découvert que MSBuild.exe ne gérait pas correctement toutes les dépendances dont nous disposons.

En travaillant avec Microsoft, nous avons pu résoudre certains problèmes, mais pas tous. Si ma mémoire est bonne, nous ne pourrions jamais obtenir les assemblages C # qui dépendaient de dll C ++ gérées. Nous avons donc fini par créer un script de construction personnalisé appelé devenv.exe à partir de la ligne de commande et tout a bien fonctionné.

Bien sûr, c'était avec VS2005, cela pourrait être corrigé maintenant, mais le script fonctionne toujours, nous n'avons donc pas revu le problème.