Je suis conscient qu'il y a d'autres NAnt et MSBuild sur Stack Overflow, mais je n'ai pas trouvé de comparaison directe entre les deux et voici donc la question.
Quand doit-on choisir NAnt plutôt que MSBuild ? Lequel est le meilleur pour quoi ? NAnt est-il plus adapté aux projets domestiques/open source et MSBuild aux projets professionnels ? Quelle est l'expérience avec l'un ou l'autre des deux ?
J'ai fait une enquête similaire cette semaine. Voici ce que j'ai pu déterminer :
NAnt :
MSBuild :
Différences subjectives : (YMMV)
Vous pouvez modifier 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 : ou mettez simplement vos personnalisations dans un fichier .build séparé (ou autre) et importez+exécutez le à partir de votre fichier .csproj. Vous n'aurez alors à modifier le fichier .csproj qu'une seule fois, et vous pourrez ajouter le fichier .build à votre solution. Double-cliquez et vous éditez comme n'importe quel autre fichier. Vous pouvez associer les fichiers .build à l'éditeur XML dans vos options.
Il existe une tâche MSBuild CCNet - Les détails peuvent être trouvés à l'adresse suivante : confluence.public.thoughtworks.org/display/CCNET/MsBuild+Task
L'un des principaux attraits 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 vous avez une plateforme qui peut construire des projets sur des machines propres. Il n'est pas nécessaire d'installer le béhémoth Visual Studio. NAnt, en revanche, doit être explicitement installé avant qu'une construction puisse être déclenchée.
Pour mémoire, j'ai utilisé NMake, Make, Ant, Rake, NAnt et MSBuild pour des constructions non triviales dans le passé (dans cet ordre). Mon préféré est MSBuild, sans hésiter (et je ne le favorise pas parce que "c'est ce que Visual Studio utilise"). À mon avis, 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 étonnantes avec lui.
Je recommanderais donc de regarder MSBuild si vous gravitez également vers la programmation fonctionnelle ou logique - si vous êtes prêt à investir un peu de temps et d'effort avant de voir des résultats tangibles (bien sûr, je crois aussi fermement que l'investissement finit par payer et que vous pouvez faire des choses plus puissantes plus efficacement).
Wow ! Je ne savais pas que MSBuild était livré avec le runtime. C'est assez cool et je peux certainement voir des avantages là. 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 qu'on l'a "compris".
Msbuild a en fait un certain nombre de dépendances sur des fichiers de divers sdks qui ne deviennent apparents que lors de l'invocation de certaines cibles. Ainsi, bien que msbuild soit disponible en sortie de boîte, il peut ne pas fonctionner.
Une chose à ajouter : non seulement il est possible d'appeler des assemblages .NET à partir de msbuild, ce qui donne accès à un grand nombre de fonctions très pratiques (par exemple, tout ce qui se trouve dans Systme.IO.Path peut être utile dans les scripts de construction), mais il est également possible d'écrire du code C# dans les fichiers msbuild et de le faire exécuter. Ce qui est tout simplement génial. msdn.microsoft.com/fr/us/library/dd722601.aspx Et si les choses deviennent trop compliquées, la rédaction de tâches personnalisées est également un jeu d'enfant.
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 a été conçu.
NAnt est plus facilement éditable à la main, à mon avis - surtout si vous connaissez déjà Ant. NAnt peut appeler MSBuild très facilement avec NAntContrib. Ainsi, je crée à la main un script NAnt pour faire des choses comme copier les fichiers construits, nettoyer etc - et appeler MSBuild pour faire la partie réelle "transformer mon code source C# en assemblages".
Si vous voulez un exemple de cela, regardez ma Fichier de construction des tampons de protocole . (Je ne prétends pas que c'est un fabuleux NAnt script, mais il fait le travail).
@Mehrdad : Oui, à un moment donné, je dois vraiment essayer de faire compiler Protocol Buffers sur Mono... actuellement, il y a un bug gmcs qui l'empêche de fonctionner :( L'idée a toujours été qu'il fonctionnerait éventuellement sur Mono.
Les gars, mono utilise XBuild et il est facile de porter MSBuild vers XBuild. Regardez ceci : mono-project.com/Porting_MSBuild_Projects_To_XBuild .
NAnt a plus de fonctionnalités, mais MSBuild possède une bien meilleure structure fondamentale (roches de métadonnées d'éléments), ce qui facilite grandement l'élaboration 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 :
KISS \= Utiliser MSBuild.
Pourquoi ajouter quelque chose d'autre dans le mélange quand vous avez quelque chose qui fera un travail raisonnable hors de la boîte ? Quand MSBuild est arrivé, NAnt est mort. Et Mono aura une implémentation MSBuild, ( xbuild ).
SEC \= Utiliser MSBuild.
Demandez-vous ce que vous attendez d'un système de construction. Je veux un système de construction qui soit également utilisé par mes clients. IDE plutôt que de maintenir deux configurations différentes.
Personnellement, j'aimerais entendre de vrais arguments en faveur de NAnt, car je n'en vois aucun qui tienne la route.
"When msbuild arived, nant died" -- Je pense que c'est l'argument décisif, même sans VS (que je n'utilise pas).
Je suis d'accord. DotNet 1.1 n'avait pas de msbuild.exe. On était donc dans la merde à l'époque. Depuis 2.0, msbuild.exe et les bibliothèques supplémentaires font beaucoup. Et écrire une MsBuild-Task personnalisée a une courbe d'apprentissage, mais j'en ai écrit environ 10 au cours des années.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
