NAnt ou MSBuild, lequel choisir et quand?

160

Je suis conscient qu'il existe d'autres questions liées à NAnt et MSBuild sur Stack Overflow, mais je n'ai pas pu trouver de comparaison directe entre les deux et voici donc la question.

Quand faut-il choisir NAnt sur MSBuild? Lequel est le meilleur pour quoi? NAnt est-il plus adapté pour les projets domestiques / open source et MSBuild pour les projets professionnels? Quelle est l'expérience avec l'un des deux?

Yordan Pavlov
la source

Réponses:

97

J'ai fait une enquête similaire cette semaine. Voici ce que j'ai pu déterminer:

NAnt:

  • Multiplateforme (prend en charge Linux / Mono). Cela peut être pratique pour installer un site Web sur plusieurs cibles (c'est-à-dire Linux Apache et Windows IIS), par exemple.
  • 95% de syntaxe similaire à Ant (facile à saisir pour les utilisateurs Ant actuels ou les constructeurs Java)
  • Intégration avec NUnit pour exécuter des tests unitaires dans le cadre de la construction et avec NDoc pour la documentation de production.

MSBuild:

  • Intégré à .NET.
  • Intégré à Visual Studio
  • Facile à démarrer avec MSBuild dans Visual Studio - tout est dans les coulisses. Si vous souhaitez approfondir, vous pouvez modifier manuellement les fichiers.

Différences subjectives: (YMMV)

  • La documentation NAnt est un peu plus simple. Par exemple, la référence des tâches MSBuild répertorie «Tâche Csc - Décrit la tâche Csc et ses paramètres» (merci pour «l'aide»?), Vs la référence des tâches NAnt «csc - Compile les programmes C #». MISE À JOUR: J'ai remarqué que la documentation MSBuild a été améliorée et est bien meilleure maintenant (probablement à égalité avec NAnt).
  • Il n'est pas facile de comprendre comment modifier la source du script de génération (fichier *. * Proj) directement à partir de Visual Studio. Avec NAnt, je demande simplement à Visual Studio de traiter le script .build comme un fichier XML.
  • Apparemment, dans Visual Studio, les projets d'application Web n'obtiennent pas de fichier *. * Proj par défaut, j'ai donc eu beaucoup de mal à comprendre comment même faire exécuter MSBuild sur le mien pour créer un script de déploiement.
  • NAnt n'est pas intégré à Visual Studio et doit être ajouté, soit avec un complément, soit comme un «outil externe». C'est un peu pénible à mettre en place.
  • (Modifier :) Un de mes collègues en a parlé - si vous souhaitez configurer une machine de construction à l'aide de CruiseControl pour une intégration continue, CruiseControl s'intègre parfaitement à NAnt dès la sortie de la boîte. MISE À JOUR: CruiseControl a également une tâche MSBuild .
  • Veuillez consulter les commentaires ci-dessous pour une discussion complète et à jour des différences subjectives.
Ogre Psaume33
la source
vous pouvez éditer un fichier .proj mais après avoir déchargé le projet (il devrait y avoir une option "Décharger" dans le menu contextuel du projet)
Yordan Pavlov
18
@Yordan: ou mettez simplement vos personnalisations dans un fichier .build séparé (ou autre) et importez + exécutez-le à partir de votre fichier .csproj. Ensuite, vous ne devez éditer le .csproj qu'une seule fois et pouvez ajouter le fichier .build à votre solution. Double-cliquez et vous modifiez comme n'importe quel autre fichier. Peut mapper les fichiers .build à l'éditeur XML dans vos options.
Kent Boogaart le
9
Il existe une tâche MSBuild CCNet - Les détails peuvent être trouvés à: confluence.public.thoughtworks.org/display/CCNET/MsBuild+Task
Gavin Miller
2
Il est à noter que vous n'avez pas besoin de modifier les fichiers .csproj eux-mêmes. Vous pouvez utiliser un fichier MyProject.csproj.user pour effectuer ces modifications, laissant votre fichier .csproj propre et vierge. MSBuild sait rechercher ces fichiers .user et les importera automatiquement dans le processus de construction. Voir: ahmed0192.blogspot.com/2006/11/…
CleverPatrick
3
@CleverHuman, ce fichier .user ne contient-il pas généralement des mods spécifiques à l'utilisateur pour le projet que vous ne consigneriez pas normalement avec le reste du projet? J'utilise la suggestion de Kent depuis des années et cela fonctionne très bien. Vous modifiez le fichier PROJ une fois pour inclure un deuxième fichier PROJ, puis ajoutez le deuxième fichier PROJ à votre projet. À partir de là, vous pouvez facilement personnaliser ce deuxième fichier PROJ sans avoir à passer par ce processus de déchargement / rechargement. J'ai tendance à me pencher vers MSBuild pour cette raison.
DarinH
77

L'un des principaux avantages de MSBuild pour moi (sur les plates-formes Windows) est qu'il fait partie de .NET lui-même. Cela signifie que toute machine Windows qui est à jour avec Windows Update aura MSBuild disponible. Ajoutez à cela le fait que le compilateur C # fait également partie de .NET lui-même et que vous disposez d'une plate-forme qui peut créer des projets sur des machines propres. Pas besoin d'installer le mastodonte de Visual Studio. NAnt, d'autre part, doit être explicitement installé avant qu'une compilation puisse être déclenchée.

Pour mémoire, j'ai utilisé NMake, Make, Ant, Rake, NAnt et MSBuild sur des versions non triviales dans le passé (dans cet ordre). Mon préféré est MSBuild, haut la main (et je ne le préfère pas car "c'est ce que Visual Studio utilise"). IMHO, c'est un outil de construction très sous-estimé.

Je comparerais NAnt vs MSBuild à la différence entre la programmation procédurale et fonctionnelle. NAnt est assez simple et vous obtenez ce que vous voyez. MSBuild, par contre, demande un peu plus de réflexion. La courbe d'apprentissage est plus raide. Mais une fois que vous l'avez "compris", vous pouvez faire des choses incroyables avec.

Je recommanderais donc de regarder MSBuild si vous êtes également tourné vers la programmation de style fonctionnel ou logique - si vous êtes prêt à investir un peu de temps et d'efforts avant de voir des résultats tangibles (bien sûr, je crois aussi fermement que l'investissement finit par payer et vous peut faire des choses plus puissantes plus efficacement).

Milan Gardian
la source
11
Hou la la! Je ne savais pas que MSBuild était livré avec le runtime. C'est plutôt cool et je peux certainement y voir des avantages. Cependant, je ne comprends pas la comparaison entre fonctionnel / procédural. Il serait intéressant d'entendre ce qui rend MSBuild tellement plus puissant une fois que l'on «comprend».
Scott Saad
2
Msbuild a en fait un certain nombre de dépendances sur les fichiers de divers sdks qui ne deviennent apparentes que lors de l'appel de certaines cibles. Ainsi, bien que msbuild soit disponible immédiatement, il peut ne pas fonctionner.
Sam Shiles du
6
une chose à ajouter: non seulement il est possible d'appeler des assemblys .NET à partir de msbuild, ce qui donne accès à de nombreuses fonctions très pratiques (par exemple, tout dans Systme.IO.Path peut être utile dans les scripts de construction) , il est également possible d'écrire du code C # brut dans des fichiers msbuild et de le faire exécuter. Ce qui est tout simplement génial. msdn.microsoft.com/en-us/library/dd722601.aspx Et si les choses deviennent trop compliquées, l'écriture de tâches personnalisées est également un jeu d'enfant.
stijn
1
De Wikipedia: « MSBuild était auparavant fourni avec .NET Framework; à partir de Visual Studio 2013, cependant, il est fourni avec Visual Studio à la place.»
DavidRR
MSBuild (Microsoft Build Tools 2013) peut également être téléchargé indépendamment de Visual Studio 2013 ici .
DavidRR
45

Personnellement, j'utilise les deux - pour le même projet.

MSBuild est excellent pour créer des solutions et des projets Visual Studio - c'est pour cela qu'il est fait.

NAnt est plus facilement modifiable à la main, à mon avis - en particulier si vous connaissez déjà Ant. NAnt peut appeler MSBuild très facilement avec NAntContrib. Donc, je crée à la main un script NAnt pour faire des choses comme la copie de fichiers construits, le nettoyage, etc. - et j'appelle MSBuild pour faire la partie "transformer mon code source C # en assemblages".

Si vous voulez un exemple de cela, regardez mon fichier de construction Protocol Buffers . (Je ne dirais pas que c'est un fabuleux script NAnt, mais il fait le travail.)

Jon Skeet
la source
1
Et il prend en charge Mono. Le support MSBuild de Mono est nul.
Mehrdad Afshari
@Mehrdad: Oui, à un moment donné, je dois vraiment essayer de faire compiler Protocol Buffers sur Mono ... actuellement, il y a un bogue gmcs qui l'empêche de fonctionner: (L'idée était toujours que cela finirait par fonctionner sur Mono.
Jon Skeet
1
Les gars, mono utilise XBuild et il est facile de porter MSBuild vers XBuild. Vérifiez ceci: mono-project.com/Porting_MSBuild_Projects_To_XBuild .
fyasar
20

NAnt a plus de fonctionnalités prêtes à l'emploi , mais MSBuild a une structure fondamentale bien meilleure (les métadonnées des éléments), ce qui facilite beaucoup la création de scripts MSBuild réutilisables.

MSBuild prend un certain temps à comprendre, mais une fois que vous le faites, c'est très agréable.

Matériel d'apprentissage:

Konstantin Tarkus
la source
38
Hé, j'ai entendu parler de ces livres :)
Sayed Ibrahim Hashimi
19

KISS = Utilisez MSBuild.

Pourquoi ajouter quelque chose d'autre dans le mix quand vous avez quelque chose qui fera un travail raisonnable hors de la boîte? Lorsque MSBuild est arrivé, NAnt est mort. Et Mono aura une implémentation MSBuild, ( xbuild ).

DRY = Utilisez MSBuild.

Demandez-vous ce que vous attendez d'un système de construction? Je veux un système de construction qui est également utilisé par mon IDE plutôt que le maintien de deux configurations différentes.

Personnellement, j'aimerais entendre de vrais arguments en faveur de NAnt, car je ne peux pas penser à ceux qui tiennent vraiment la route.

écureuil
la source
2
"Quand msbuild est arrivé, nant est mort" - je pense que c'est le clincher, même sans VS (que je n'utilise pas).
harpo
Je suis d'accord. DotNet 1.1 n'avait pas msbuild.exe. Nous étions donc foutus à l'époque. Depuis 2.0, msbuild.exe et les bibliothèques supplémentaires font beaucoup. Et l'écriture d'une MsBuild-Task personnalisée a une courbe d'apprentissage, mais j'en ai écrit environ 10 au fil des ans.
granadaCoder
1
Je dois être d'accord, vous devriez utiliser le même outil pour créer en tant que développeur que le serveur de construction utilisera, ce qui vous permettra d'échouer plus rapidement.
krystan honore
14

Une chose que j'ai remarquée dans plusieurs affiches était de devoir éditer manuellement les fichiers .csproj (ou .vbproj, etc.).

MSBuild permet la personnalisation de ces fichiers. * Proj grâce à l'utilisation de fichiers .user. Si j'ai un projet nommé MyCreativelyNamedProject.csproj et que je souhaite personnaliser les tâches MSBuild à l'intérieur de celui-ci, je peux créer un fichier nommé MyCreativelyNamedProject.csproj.user et utiliser les CustomBeforeMicrosoftCommonTargets et CustomAfterMicrosoftCommonTargets pour personnaliser ces fichiers.

En outre, NAnt et MSBuild peuvent être personnalisés selon le contenu de votre cœur via des tâches MSBuild personnalisées et des extensions NantContrib.

Donc, utiliser NAnt ou MSBuild revient vraiment à la familiarité:

  • Si vous connaissez déjà Ant, utilisez NAnt. La courbe d'apprentissage sera très facile.
  • Si vous n'êtes pas familiarisé avec l'un ou l'autre de ces outils, MSBuild est déjà intégré à Visual Studio et ne nécessite aucun outil supplémentaire.

Il convient également d'ajouter que MSBuild est à peu près garanti de fonctionner avec toutes les nouvelles versions de .NET et Visual Studio dès leur sortie, alors que NAnt peut avoir un certain décalage.

CleverPatrick
la source
1
+1 pour signaler le décalage entre les versions .net et les versions nant. Je me souviens quand .net 3.5 est sorti et que j'ai dû utiliser un nant.exe.config piraté depuis des réseaux pour que les choses fonctionnent. Pas drôle.
mmacaulay
9
Selon de nombreux articles ici, ces fichiers .USER contiennent + des informations spécifiques à l'utilisateur + qui ne devraient pas être archivés, donc ce serait le dernier endroit où je voudrais mettre des personnalisations de construction ... Toutes les personnalisations de construction par définition ne devraient pas 'pas être spécifique à l'utilisateur, et donc ne devrait pas aller dans ces fichiers .user ...
DarinH
1
D'accord avec drventure; Les fichiers .user sont comme son nom l'indique pr user et ils ne devraient même pas être archivés dans votre référentiel de contrôle de source. Ce n'est PAS l'endroit pour automatiser la construction.
Kjetil Klaussen
10

J'utilise les deux dans la mesure où mes scripts NAnt appellent MSBuild. Ma principale raison de rester avec NAnt est l' isolement . Laissez-moi vous expliquer pourquoi je pense que c'est important:

  1. Ajout de dépendances à votre projet. Le fichier de construction NAnt est étranger à Visual Studio (dans mon cas, je considère cela comme un pro), donc Visual Studio n'essaye pas d'en faire quoi que ce soit. Les tâches MSBuild sont intégrées et font donc partie de la solution et peuvent faire référence à d'autres tâches MSBuild. J'ai reçu le code source de quelqu'un d'autre pour découvrir que je ne pouvais pas créer, car les tâches de la communauté MSBuild n'étaient pas installées. Ce que je trouve particulièrement frustrant, c'est que Visual Studio ne se construit tout simplement pas et a généré un tas d'erreurs qui m'ont fait perdre du temps au débogage. Ceci, malgré le fait que la construction demandée aurait pu aller de l'avant (comme une version de débogage par exemple) sans certains des extras de la tâche MSBuild. En bref: je n'aime pas ajouter des dépendances à mon projet si je peux l'éviter .

  2. Je ne fais pas confiance à Visual Studio dans la mesure où je pourrais lancer son équipe de développement. Cela remonte aux premiers jours de Visual Studio quand il massacrait mon HTML. Je n'utilise toujours pas le concepteur par exemple (lors d'une conférence récemment, j'ai trouvé que des collègues faisaient de même). J'ai constaté que Visual Studio peut bousiller les dépendances et les numéros de version dans le fichier DLL (je ne peux pas le répliquer, mais cela s'est produit dans un projet de manière cohérente et a causé beaucoup de chagrin et de perte de temps). J'ai eu recours à une procédure de génération qui utilise Visual Studio pour générer uniquement en mode débogage. Pour la production, j'utilise NAnt pour tout contrôler en externe . Visual Studio ne peut tout simplement plus interférer si je construis en utilisant NAnt.

PS: Je suis développeur Web et ne fais pas de développement Windows Forms.

Peter Mortensen
la source
6

Bien que je ne sois pas très familier avec MsBuild, j'ai l'impression que certaines des différences clés des deux côtés peuvent être complétées par des ajouts:

J'ai récemment dû construire un projet Silverlight à Nant. J'ai découvert que la vie serait plus facile si je faisais cela avec MsBuild - j'ai fini par appeler une tâche MsBuild à partir d'un script Nant, donc je suppose que ce n'est pas trop inhabituel de mélanger et de faire correspondre les deux.

Au-delà de cela, je suppose que ce sera une question de préférence personnelle - évidemment, vous pouvez gérer une partie / la plupart des fonctionnalités de MsBuild à partir de Visual Studio, si c'est votre truc. Nant semble plus flexible et mieux adapté si vous préférez écrire des scripts à la main, et si vous venez du monde Java, vous serez probablement à l'aise avec lui.

mmacaulay
la source
Bon point. Les deux solutions peuvent facilement être étendues et personnalisées de la manière souhaitée.
CleverPatrick
2

J'ai fini par utiliser les deux. Lors de la refonte de notre système de construction, j'étais confronté à un problème délicat. À savoir, je ne pouvais pas me débarrasser de .vcproj (et de la famille) parce que nous utilisions tout le monde VS pour mettre à jour les fichiers, les paramètres et les configurations du projet. Donc, sans un énorme processus de duplication et d'erreurs, nous ne pourrions pas baser notre système de construction sur un nouvel ensemble de fichiers.

Pour cette raison, j'ai décidé de conserver les fichiers 'proj' de VS et d'utiliser MSBuild (ce sont des fichiers MSBuild, au moins VS2005 et VS2008 utilisent des fichiers de projet MSBuild). Pour tout le reste (configuration personnalisée, tests unitaires, packaging, préparation de la documentation ...) j'ai utilisé NAnt.

Pour une intégration continue, j'ai utilisé CruiseControl. Nous avons donc eu des scripts CC qui ont déclenché des travaux NAnt, qui pour la construction utilisaient MSBuild.

Une dernière remarque: MSBuild ne prend PAS en charge les projets d'installation! Vous êtes donc obligé d'appeler DevEnv.com ou d'utiliser directement Visual Studio. C'est ce que j'ai fini par faire, mais j'ai désactivé le projet d'installation par défaut à partir de toutes les configurations de solution, car les développeurs n'auraient normalement pas besoin de les construire, et s'ils le font, ils peuvent choisir manuellement de les construire.

Cendre
la source
1

La documentation et les didacticiels disponibles pour NAnt facilitent l'apprentissage des scripts de construction avec NAnt. Une fois que j'ai maîtrisé NAnt et créé des scripts de construction, j'ai commencé à traduire ces connaissances vers MSBuild (j'ai fait X dans NAnt, comment puis-je faire X dans MSBuild?). La documentation de Microsoft suppose généralement un niveau de connaissances assez élevé avant d'être utile.

La raison du passage de NAnt à MSBuild est que MSBuild est plus actuel. Malheureusement, la dernière version de NAnt date du 8 décembre 2007, alors que MSBuild 4.0 (.NET 4.0) n'est pas loin. Il semble que le projet NAnt soit mort.

Si vous trouvez une bonne documentation pour quelqu'un qui commence tout juste à apprendre à créer des scripts de construction à l'aide de MSBuild, ignorez NAnt et passez directement à MSBuild. Si NAnt sort un jour avec une nouvelle version, j'envisagerais de m'en tenir à NAnt, mais ils sont à la traîne maintenant.

Mcdon
la source
1
Depuis juin 2012, la version 0.92 de NAnt est disponible sur le site Web: nant.sourceforge.net ET prend en charge .Net 4.0.
Brett Rigby
0

Nous utilisons les deux. NAnt est responsable de tous les "scripts", comme la copie, le déploiement sur IIS , la création de packages et MSBuild est responsable de la construction de la solution. Ensuite, nous pouvons éviter les problèmes avec .NET 4.0 non pris en charge par une nouvelle version de NAnt.

NAnt est également plus évolutif. Si nous voulons migrer les scripts de déploiement vers les serveurs de production, nous copions uniquement le fichier de construction et installons une version appropriée de .NET - aucun problème de Visual Studio avec les fichiers csproj :)

Leszek Wachowicz
la source
0

YDeliver by Manoj est un framework de build construit sur PSake. Il dispose d'un riche ensemble de fonctions de bibliothèque, de la capacité de définir des flux de travail et nous l'avons utilisé pour mettre en production plus de six projets d'entreprise.

Utilisez-le avec TeamCity , CruiseControl ou tout ce qui peut exécuter PowerShell .

Zasz
la source
0

Nous utilisons FlubuCore. Il s'agit d'une bibliothèque C # open source pour créer des projets et exécuter des scripts de déploiement à l'aide de code C #.

Exemple simple d'utilisation de flubu:

protected override void ConfigureTargets(ITaskContext session)
{           

    var compile = session.CreateTarget("compile")
        .SetDescription("Compiles the solution.")
        .AddTask(x => x.CompileSolutionTask())
        .DependsOn("generate.commonassinfo");
}

Vous pouvez trouver plus d'informations sur flubu et comment commencer ici: choice-for-build-tool-msbuild-nant-or-something-else

Stan88
la source