Dois-je passer de nant à msbuild ?

StackOverflow https://stackoverflow.com/questions/10634

Question

J'utilise actuellement nant, ccnet (régulateur de vitesse), svn, mbunit.J'utilise msbuild pour réaliser ma construction sln simplement parce que c'était plus simple à débourser.

Y a-t-il des avantages à basculer l’intégralité de mon script de build vers MSBuild ?Je dois être capable d'exécuter des tests, des tests de style watir, un déploiement xcopy.Est-ce plus facile ?

Mise à jour:Des fonctionnalités intéressantes qui me feraient passer de nant à msbuild ?

Était-ce utile?

La solution

J'aime MSBuild.L'une des raisons est que les fichiers .csproj sont des fichiers msbuild et que la construction dans VS est comme la construction en ligne de commande.Une autre raison est le bon support de TeamCity, le serveur CI que j'utilise.Si vous commencez à utiliser MSBuild et que vous souhaitez effectuer davantage de tâches personnalisées dans votre processus de génération, obtenez le Tâches de la communauté MSBuild.Ils vous confient un tas de tâches supplémentaires intéressantes.Je n'utilise plus NAnt depuis plusieurs années maintenant et je ne l'ai pas regretté.

De plus, comme Ruben le mentionne, il y a les Tâches du DDC tâches sur CodePlex.

Pour encore plus de plaisir, il y a le Pack d'extension MSBuild sur CodePlex, qui comprend une tâche Twitter.

Autres conseils

Mon conseil est tout le contraire : évitez MSBuild comme la peste.NANT est beaucoup plus facile à configurer votre build pour effectuer des tests automatiques, à déployer sur plusieurs environnements de production, à intégrer avec cruisecontrol pour un environnement d'entrée, à intégrer avec le contrôle de code source.Nous avons enduré tellement de difficultés avec TFS/MSBuild (utilisation de TFSDeployer, de scripts PowerShell personnalisés, etc.) pour qu'il fasse ce que nous avons pu faire avec NANT prêt à l'emploi.Ne perdez pas votre temps.

La raison la plus impérieuse d’utiliser MSBuild (au moins dans .NET 3.5 et au-delà) : le moteur de build peut construire simultanément.

Cela signifie une énorme accélération de vos builds si vous disposez de plusieurs cœurs/processeurs.

Avant la version 3.5, MSBuild n'effectuait pas de builds parallèles.

Je pense que MSBuild et Nant sont assez comparables.Si vous en utilisez un, je ne basculerais généralement pas entre eux à moins qu'il n'y ait une fonctionnalité intéressante qui manquait dans le produit que vous avez sélectionné.

J'utilise personnellement MSBuild pour tout nouveau projet, mais votre kilométrage peut varier.

J'espère que cela pourra aider!

Modifier: @ChanChan - @Jon mentionne que Nant ne crée pas d'applications .NET 3.5.Cela peut être une raison suffisante pour soit les modifier, soit au moins les utiliser en parallèle.Au fur et à mesure que je m'oriente davantage vers MSBuild, je ne suis probablement pas la personne la plus informée pour mettre en évidence d'autres produits phares avec l'une ou l'autre technologie.

Modifier: Il semble que Nant crée désormais des applications .NET 3.5.

NAnt existe depuis plus longtemps et est un produit considérablement plus mature, et également plus facile à utiliser, selon l'OMI.Il existe un grand savoir-faire communautaire à exploiter, et il est également multiplateforme, si vous souhaitez créer des applications pouvant fonctionner sous Mono ainsi que .NET et Silverlight.Prêt à l'emploi, il fait bien plus que MSBuild.Oh oui, et vous pouvez appeler MSBuild depuis NAnt (OK, depuis NAntContrib) :-)

Du côté négatif, NAnt et son projet frère NAntContrib semblent avoir stagné, la mise à jour la plus récente datant de fin 2007.

Le principal avantage que je vois de MSBuild est qu'il est livré avec le .NET Framework, c'est donc un produit de moins à installer ;et il y a un développement plus actif en cours (bien que par endroits pour rattraper l'ancien NAnt).

Personnellement, je trouve sa syntaxe un peu plus difficile à comprendre, mais je suis sûr qu'une exposition continue à ti rendrait les choses plus faciles.

Conclusion?Si vous travaillez avec des scripts NAnt existants, respectez-les, cela ne vaut pas la peine de les porter.Si vous démarrez un nouveau projet et que vous vous sentez aventureux, essayez MSBuild.

Nous sommes également passés de nant à msbuild.Si votre build est assez standard, vous n'aurez pas beaucoup de problèmes pour la configurer, mais si vous avez beaucoup de tâches de build spécifiques, vous devrez écrire des tâches de build MS personnalisées, car il y a beaucoup moins de tâches personnalisées pour msbuild.

Si vous souhaitez afficher des résultats de construction raisonnables, vous devrez jouer avec des enregistreurs personnalisés, etc.L’ensemble de la constitution de l’équipe n’est pas aussi mûr que Nant.

Mais le véritable avantage est l’intégration avec les services de contrôle de source et de reporting TFS.Si vous n'utilisez pas TFS comme système de contrôle de code source, cela n'en vaut pas la peine.

  • Ne changez pas sauf si vous avez une raison très convaincante (au moins).
  • NAnt est open source et si ce n'était pas le cas, je ne serais pas en mesure de personnaliser notre système de build, MSBuild ne l'est pas.
  • NAnt peut facilement exécuter MSBuild, je ne suis pas sûr de l'inverse.
  • Les scripts MSBuild sont déjà écrits pour vous si vous utilisez VS2005 ou une version plus récente (les fichiers du projet sont Fichiers MSBuild.)
  • Si vous utilisez NAnt et que vous utilisez VS pour modifier les fichiers, paramètres et configurations du projet, vous devrez écrire un outil de conversion/synchronisation pour mettre à jour vos fichiers NAnt à partir des fichiers du projet VS.

@Brad Leach

En général, je ne basculerais pas entre eux à moins qu'il ne manque une fonctionnalité intéressante.

quelles sont les raisons impérieuses d’utiliser msbuild ?y a-t-il des inconvénients ?

Jusqu'à présent, j'obtiens un plutôt bon "non, ne vous embêtez pas" de votre réponse.

Je pense qu'ils sont relativement comparables tant en termes de fonctionnalités que de facilité d'utilisation.Juste parce qu'il est basé sur C#, je trouve que msbuild est plus facile à utiliser que Nants, même si ce n'est pas une raison impérieuse de changer.

Qu'est-ce que Nant ne fait pas exactement pour vous ?Ou espérez-vous simplement qu'il y ait une fonctionnalité intéressante que vous pourriez manquer ?:)

Une chose très intéressante à propos de C# est que si vous disposez du framework .net, vous disposez de tout ce dont vous avez besoin pour exécuter msbuild.C'est fantastique lorsque vous travaillez sur de grandes équipes/projets et que vous avez un roulement de personnel/matériel.

Personnellement, je préfère les SCons aux deux :)

La principale raison pour laquelle j'utilise toujours nAnt sur msbuild pour mes builds automatisés est que j'ai un contrôle plus granulaire sur mes builds.Étant donné que msbuild utilise csproj et son fichier de construction, toutes les sources de ce projet sont compilées en un seul assembly.Ce qui m'amène à avoir beaucoup de projets dans ma solution pour les grands projets où je sépare la logique.Eh bien, avec Nant, je peux organiser ma construction de manière à compiler ce que je veux en plusieurs assemblys à partir d'un même projet.

J'aime cette voie, car elle m'évite d'avoir à avoir de nombreux fichiers de projet dans ma solution.Je peux avoir un projet avec des dossiers répartissant les calques, puis utiliser nant pour créer chaque calque dans son propre assemblage.

Cependant, j'utilise à la fois nant et msbuild conjointement pour certaines tâches de construction, comme la création d'applications WPF.Il est tout simplement beaucoup plus facile de compiler une application WPF avec la cible msbuild dans nant.

Pour terminer, le point de ma réponse est que j'aime les utiliser côte à côte, mais lorsque j'utilise msbuild dans cette configuration, c'est généralement pour une compilation directe, sans effectuer de tâches d'automatisation de construction comme copier des fichiers dans un répertoire, générer la documentation d'aide, ou exécuter mes tests unitaires par exemple.

En fait, j'essaie toujours de résoudre cette question moi-même, mais il y a un gros bonus pour MSBuild ici :utiliser le même fichier de build pour l'intégration continue locale en appelant directement msbuild.exe, tout en pouvant également utiliser l'intégration continue côté serveur de VSTS avec le même fichier de build (bien que très probablement des propriétés/paramètres différents).

c'est à dire.par rapport à la prise en charge par TeamCity des scripts MSBuild, VSTS seulement prend en charge les scripts MSBuild !J'ai déjà contourné ce problème dans le passé en exécutant NAnt à partir de MSBuild ;J'ai vu d'autres recommander cette pratique ainsi que l'inverse, mais cela me semble tout simplement compliqué, alors j'essaie de ne pas le faire si je peux l'éviter.Ainsi, lorsque vous utilisez « la pile Microsoft complète » (VSTS et TFS), je vous suggère de vous en tenir aux scripts MSBuild.

Nant a plus de fonctionnalités prêtes à l'emploi, mais MSBuild a une bien meilleure structure fondamentale (roches de métadonnées d'élément), ce qui facilite grandement la création de scripts MSBuild réutilisables.

MSBuild prend un certain temps à comprendre, mais une fois que vous l'avez fait, c'est très sympa.

Matériel d'apprentissage:

Je ne vois aucune raison de changer.MsBuild lui-même vous enferme dans le framework que vous utilisez.Si vous utilisez NAnt, vous pouvez l'utiliser dans de nombreux frameworks et confier à msbuild le travail de construction à votre place.

Je suis fan de NAnt à cet égard, car cela vous découple un peu du framework.

J'ai créé un framework qui met des conventions dans des builds automatisés et je l'ai construit sur NAnt.Il s'appelle UppercuT et c'est le Build Framework incroyablement facile à utiliser.

Des constructions automatisées aussi simples que (1) le nom de la solution, (2) le chemin de contrôle des sources, (3) le nom de l'entreprise pour la plupart des projets !

http://code.google.com/p/uppercut/

Quelques bonnes explications ici : Uppercut

MSBuild étant intégré à Visual Studio, les programmeurs ont moins de difficultés à utiliser le système de build.Cela revient principalement au fait qu'il leur suffit d'aller "Construire la solution" et que tout fonctionne, plutôt que de devoir utiliser des étapes de construction personnalisées et d'autres choses du même genre, ou, pire encore, de forcer les développeurs à construire en lançant une sorte de script externe.

Maintenant, j'ai surtout tendance à préférer MSBuild à NAnt car c'est plus simple.Bien sûr, NAnt a beaucoup plus de fonctionnalités, est plus puissant, etc., mais il peut vite devenir incontrôlable.Si vous et vos ingénieurs de construction avez la discipline nécessaire pour garder les scripts NAnt simples, alors tout va bien.Cependant, j'ai vu trop de systèmes basés sur NAnt aller vers le sud à un point où personne ne comprend plus ce qu'ils font, et il n'y a pas de véritable moyen de le déboguer à part faire l'équivalent d'un bon vieux printf.Au moment où vous commencez à utiliser une instruction if/else ou une boucle for, c'est là, à mon humble avis, que ça commence à sentir.

D'un autre côté, MSBuild dispose d'une base solide basée sur des métadonnées et une syntaxe moins verbeuse.Sa simplicité (ou son manque de fonctionnalités...selon la façon dont vous le voyez) vous oblige à écrire une logique dans du code .NET via de nouvelles tâches, au lieu d'écrire une logique dans un balisage XML.Cela encourage la réutilisation et, par-dessus tout, vous permet de déboguer réellement votre système de build dans un véritable débogueur.

Le seul problème avec MSBuild est le bug pas si occasionnel (surtout dans la première version) ou le comportement obscur (bien que documenté).Et si c'est le genre de chose qui vous dérange vraiment, être lié à Microsoft.

Je suis passé de NANT à MSBuild.Le projet fonctionne sous .Net 4.0.

Mon expérience à Nant a été bonne.Le projet est en quelque sorte mort.Et lorsque .Net 4.0 est arrivé, il était temps de réévaluer le processus de construction.

Depuis la dernière sortie de Nant, MSBuild a parcouru du chemin.À ce stade, MSBuild est la voie à suivre.Il est facile à utiliser et possède de nombreuses extensions.J'ai réécrit mes scripts Nant en un jour et demi.Le script MSBuild fait 1/3 de la taille des scripts Nant.

Une grande partie du travail dans le script Nant consistait à configurer les différents environnements.Dans MsBuild/.Net 4.0, il est intégré.

J'utilise MSBuild aux côtés de Nant, car la version actuelle de Nant ne peut pas encore compiler les applications .NET 3.5 (il en était de même lors de la sortie de .NET 2.0).

La seule raison que je vois pour utiliser msbuild est si vous souhaitez utiliser un serveur de build automatisé comme le régulateur de vitesse.Si vous ne changez pas, je le laisserais tranquille.

J'utilise Nant et je l'adore.J'ai utilisé MSBuild et je l'ai détesté à cause de ceci :

  1. Microsoft vous oblige à suivre sa propre procédure de construction qui est si intrinsèque à ses activités que je n'ai au moins pas pu la faire fonctionner (j'ai dû compiler NET1.1 donc j'ai dû mélanger Nant et MSbuild).Je sais que vous pouvez créer votre propre fichier MSBuild, mais je pensais que c'était complexe à comprendre et à maintenir.

  2. Les ItemTypes pour effectuer des opérations sur les fichiers sont tout simplement trop difficiles à suivre.Vous pouvez demander à Nant de faire exactement les mêmes choses et de manière beaucoup plus simple et directe (j'ai dû créer une liste ItemType puis passer aux opérations sur les fichiers).

  3. Dans MsBuild, vous devez créer votre propre dll de tâche, dans Nant, vous pouvez le faire ou vous pouvez intégrer du code C# dans votre script, il est donc beaucoup plus facile d'avancer et de simplement construire l'ensemble du projet.

  4. Nant fonctionne avec Net1.1, pas MsBuild.

  5. Pour installer nant, je peux même décompresser et localiser dans mon propre référentiel pour l'exécuter.Installer MsBuild est beaucoup plus difficile car cela dépend de beaucoup de choses de Visual Studio, etc.(je me trompe peut-être, mais cela semble être la vérité).

Eh bien, ce sont mes opinions...

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top