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?
Réponses:
J'ai fait une enquête similaire cette semaine. Voici ce que j'ai pu déterminer:
NAnt:
MSBuild:
Différences subjectives: (YMMV)
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).
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.)
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:
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.
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é:
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.
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:
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 .
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.
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.
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.
Je suis récemment passé de NAnt à MSBuild en raison de sa capacité à créer des solutions VS. Cependant, j'utilise toujours NAnt de temps en temps.
Vous pouvez également consulter les tâches de la communauté MSBuild, comme NAntContrib.
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.
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 :)
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 .
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