Sollte ich von Nant zu Msbuild wechseln?

Question

Ich verwende derzeit Nant, Ccnet (Tempomat), Svn, Mbunit. Ich benutze msbuild, um meine SLN-Build zu machen, nur weil es einfacher war, Shell zu machen.

Gibt es irgendwelche Vorteile, mein gesamtes Build-Skript zu MSBuild zu wechseln? Ich muss in der Lage sein, Tests, Wattiltests, xcopy deploy durchzuführen. Ist das einfacher?

Update: Irgendwelche zwingenden Eigenschaften, die mich veranlassen würden, von nant zu msbuild zu wechseln?

Answer 1

ich MSBuild mögen. Ein Grund dafür ist, dass .csproj-Dateien Msbuild-Dateien sind, und das Erstellen in VS ist genauso wie das Erstellen in der Befehlszeile.Ein weiterer Grund ist der gute Support von TeamCity, dem CI-Server, den ich benutzt habe. Wenn Sie beginnen, MSBuild zu verwenden, und Sie möchten mehr benutzerdefinierte Dinge in Ihrem Build-Prozess tun, erhalten Sie die MSBuild Community Tasks. Sie geben dir eine Menge nette zusätzliche Aufgaben. Ich habe NAnt seit mehreren Jahren nicht mehr benutzt, und ich habe es nicht bereut.

Auch, wie Ruben erwähnt, gibt es die SDC Tasks Aufgaben auf CodePlex.

Für noch mehr Spaß gibt es die MSBuild Extension Pack on CodePlex, die eine Twitter-Aufgabe enthält.

Answer 2

Ich denke, dass MSBuild und Nant ziemlich vergleichbar sind. Wenn Sie eines davon verwenden, würde ich im Allgemeinen nicht zwischen ihnen wechseln, es sei denn, es gibt ein unwiderstehliches Merkmal, das in dem von Ihnen ausgewählten Produkt fehlt.

Ich persönlich benutze MSBuild für jedes neue Projekt, aber Ihre Laufleistung kann variieren.

Hoffe, dass hilft!

Bearbeiten: @ChanChan - @Jon erwähnt, dass Nant .NET 3.5 Anwendungen nicht erstellt. Dies kann Grund genug sein, sie zu ändern oder zumindest parallel zu nutzen. Da ich mich mehr in Richtung MSBuild bewegt habe, bin ich wahrscheinlich nicht die am besten informierte Person, um andere Showstopper mit beiden Technologien hervorzuheben.

Bearbeiten: Es scheint, Nant baut jetzt .NET 3.5-Anwendungen.

Answer 3

@Brad Leach

Ich würde in der Regel nicht zwischen ihnen wechseln, es sei denn es eine sehr nützliche Funktion war, die

fehlte, was die zwingenden Gründe msbuild zu benutzen? Gibt es Nachteile?

Bis jetzt bekomme ich ein ziemlich gut, "nein, störe nicht" von deiner Antwort.

Answer 4

ich MSBuild neben Nant, weil die aktuelle Version von Nant kann noch nicht .NET 3.5-Anwendungen (gleiches gilt, wenn 2.0 herauskommt .NET zuerst) kompiliert.

Answer 5

Der einzige Grund, den ich für die Verwendung von Msbuild sehen kann, ist, wenn Sie einen automatisierten Build-Server wie Tempomat verwenden möchten. Wenn Sie nicht wechseln, dann würde ich es in Ruhe lassen.

Answer 6

Ich denke, sie sind relativ vergleichbar sowohl in Funktionen und Benutzerfreundlichkeit. Nur weil ich C# -basiert bin, finde ich, dass msbuild einfacher zu handhaben ist als nants, obwohl das kaum ein zwingender Grund für einen Wechsel ist.

Was genau macht Nant für Sie nicht? Oder hoffen Sie nur, dass es eine coole Funktion gibt, die Sie verpassen könnten? :)

Eine super nette Sache über C# ist, dass, wenn Sie das .net-Framework haben, Sie alles haben, was Sie brauchen, um msbuild auszuführen. Das ist fantastisch, wenn Sie an großen Teams/Projekten arbeiten und Leute/Hardware-Umsatz haben.

Persönlich bevorzuge ich SCons über beide :)

Answer 7

Der überzeugendste Grund, MSBuild zu verwenden (zumindest in .NET 3.5 und höher) - die Build-Engine kann gleichzeitig erstellen.

Dies bedeutet eine enorme Beschleunigung in Ihren Builds in Sie haben mehrere Kerne/Prozessoren.

Vor 3.5 erstellte MSBuild keine parallelen Builds.

Answer 8

Mein Rat ist genau das Gegenteil - Vermeiden Sie MSBuild wie die Pest. NANT ist weit einfacher, Ihren Build einzurichten, um automatische Tests durchzuführen, in mehreren Produktionsumgebungen zu implementieren, in Cruisecontrol für eine Einstiegsumgebung zu integrieren und in die Quellcodeverwaltung zu integrieren. Wir haben mit TFS/MSBuild (mit TFSDeployer, benutzerdefinierten Powershell-Skripten usw.) so viel Schmerz durchgemacht, dass wir das tun konnten, was wir mit NANT aus der Box machen konnten. Verschwende keine Zeit.

Answer 9

Der Hauptgrund, warum ich noch nAnt über Msbuild für meine automatisierten Builds verwende, ist, dass ich meine Builds genauer steuern kann. Da msbuild die csproj mit seiner Build-Datei verwendet, wird die gesamte Quelle in diesem Projekt in eine Assembly kompiliert. Das führt dazu, dass ich viele Projekte in meiner Lösung für große Projekte habe, in denen ich die Logik teile. Nun, ich kann meinen Build so arrangieren, dass ich das, was ich möchte, in mehreren Assemblies von einem Projekt zusammenstellen kann.

Ich mag diese Route, weil es mich davon abhält, viele Projektdateien in meiner Lösung zu haben. Ich kann ein Projekt mit Ordnern haben, die die Schichten ausgliedern und dann nant verwenden, um jede Schicht in ihre eigene Baugruppe zu bauen.

Allerdings verwende ich beide Nant und Msbuild in Verbindung für einige Build-Aufgaben, wie WPF-Anwendungen erstellen. Es ist einfach einfacher, eine WPF-Anwendung mit dem Msbuild-Ziel in Nant zu kompilieren.

Um dies zu beenden und der Punkt meiner Antwort ist, dass ich sie nebeneinander verwenden möchte, aber wenn ich msbuild in dieser Konfiguration verwenden, ist es in der Regel für gerade kompilieren, keine Build-Automatisierungsaufgaben wie Kopieren von Dateien zu B. ein Verzeichnis, das Erstellen der Hilfedokumentation oder das Ausführen meiner Komponententests.

Answer 10

Ich bin eigentlich immer noch versucht, diese Frage selbst herauszufinden, aber es gibt einen großen Bonus für MSBuild hier: Verwenden Sie die gleiche Build-Datei für die lokale kontinuierliche Integration durch den Aufruf von msbuild.exe direkt, während auch VSTS verwenden können serverseitige kontinuierliche Integration mit derselben Build-Datei (wenn auch höchstwahrscheinlich unterschiedliche Eigenschaften/Einstellungen).

das heißt im Vergleich zu Teamcity Unterstützung für MSBuild Scripts, VSTS nur MSBuild Scripts unterstützt! Ich habe das in der Vergangenheit gehackt, indem ich NAnt von MSBuild ausführte; Ich habe gesehen, dass andere diese Übung genauso empfehlen wie das Gegenteil, aber es scheint mir nur klüger zu sein, also versuche ich es nicht zu tun, wenn ich es vermeiden kann. Wenn Sie also "den vollständigen Microsoft-Stapel" (VSTS und TFS) verwenden, würde ich vorschlagen, nur mit MSBuild-Skripten zu arbeiten.

Answer 11

Wir wechselten auch von nant zu msbuild.Wenn Ihr Build ziemlich Standard ist, dann werden Sie nicht viel Probleme haben, es einzurichten, aber wenn Sie viele spezifische Build-Aufgaben haben, müssen Sie benutzerdefinierte MS-Build-Aufgaben schreiben, da es viel weniger benutzerdefinierte Aufgaben für Msbuild gibt.

Wenn Sie vernünftige Build-Ergebnisse anzeigen möchten, müssen Sie sich mit benutzerdefinierten Loggern usw. herumschlagen. Das ganze Team Build ist nicht so reif wie Nant ist.

Der eigentliche Vorteil ist jedoch die Integration mit TFS-Quellcodeverwaltungs- und Berichtsdiensten. Wenn Sie TFS nicht als Ihr Quellcodeverwaltungssystem verwenden, lohnt es sich nicht.

Answer 12

NAnt gibt es schon länger, und ist ein wesentlich reiferes Produkt, und auch IMO einfacher zu bedienen. Es gibt eine Menge Community-Know-how, das Sie nutzen können, und es ist auch plattformübergreifend, wenn Sie daran interessiert sind, Apps zu entwickeln, die sowohl unter Mono als auch mit .NET und Silverlight laufen können. Out-of-the-Box bietet es eine ganze Menge mehr als MSBuild. Oh ja, und Sie können MSBuild von NAnt (OK, von NAntContrib) aufrufen :-)

Auf der negativen Seite scheinen NAnt und sein Schwesterprojekt NAntContrib stagniert zu haben, mit dem neuesten Update ist Ende 2007.

Die Hauptvorteile, die ich von MSBuild sehe, ist, dass es mit dem .NET Framework geliefert wird, also ist es ein Produkt weniger zu installieren; und es gibt eine aktivere Entwicklung (wenn auch an Stellen, wo der ältere NAnt aufholen kann).

Persönlich finde ich die Syntax ein wenig schwieriger zu erfassen, aber dann bin ich mir sicher, dass die fortgesetzte Exposition gegenüber Ti die Dinge einfacher machen würde.

Fazit? Wenn Sie mit vorhandenen NAnt-Skripten arbeiten, bleiben Sie dabei, es lohnt sich nicht, die Portierung zu übernehmen. Wenn du ein neues Projekt startest und dich abenteuerlustig fühlst, solltest du MSBuild ausprobieren.

Answer 13

Nant hat mehr Funktionen aus der Box, aber MSBuild hat eine viel bessere Grundstruktur (Element Metadaten Felsen), die es viel einfacher zu bauen wieder verwendbaren MSBuild Scripts macht.

MSBuild braucht eine Weile zu verstehen, aber sobald Sie es tun, ist es sehr nett.

Lernmaterialien:

• Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build
  von Sayed Ibrahim Hashimi (Jan 2009)
• Deploying .NET Applications: Learning MSBuild and ClickOnce by Sayed
  von Y. Hashimi (Sep. 2008)

Answer 14

• Don‘ t wechseln, es sei denn, Sie haben (zumindest) einen sehr überzeugenden Grund.
• NAnt ist Open Source und wenn nicht, wäre ich nicht in der Lage, unser Build-System anzupassen, MSBuild nicht.
• NAnt kann leicht MSBuild ausführen, ich bin mir nicht sicher, andersherum.
• MSBuild Scripts sind bereits für Sie geschrieben, wenn Sie VS2005 oder neuer verwenden (die Projektdateien sind MSBuild-Dateien.)
• Wenn Sie NAnt verwenden, und Sie verwenden VS Projektdateien, Einstellungen und Konfigurationen zu bearbeiten, ‚Sie Ich muss ein Konverter/Sync-Tool schreiben, um Ihre NAnt-Dateien aus den VS Project-Dateien zu aktualisieren.

Answer 15

Ich sehe keinen Grund zu wechseln. MsBuild selbst sperrt Sie in dem Framework, das Sie verwenden. Wenn Sie NAnt verwenden, können Sie es für viele Frameworks verwenden und zu msbuild migrieren, um die Bauaufgabe für Sie auszuführen.

Ich bin ein Fan von NAnt in dieser Hinsicht, weil es Sie ein wenig vom Framework entkoppelt.

Ich habe ein Framework erstellt, das Konventionen in automatisierte Builds bringt und ich baute es auf NAnt. Es heißt UppercuT und es ist das wahnsinnig einfach zu benutzende Build Framework.

Automatisierte Builds so einfach wie (1) Lösungsname, (2) Quellcode-Steuerpfad, (3) Firmenname für die meisten Projekte!

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

Einige hier gute Erklärungen: UppercuT

Answer 16

MSBuild mit Visual Studio integriert gibt Programmierer weniger Reibung das Build-System zu verwenden. Es kommt hauptsächlich darauf an, dass sie nur "Build Solution" gehen müssen, und alles funktioniert, anstatt Custom Build Steps und andere solche Dinge zu verwenden, oder, schlimmer noch, Entwickler zu zwingen, Builds zu starten, indem sie eine Art externes Skript starten.

Jetzt tendiere ich meistens MSBuild über NAnt, weil es einfacher ist. Sicher, NAnt hat viel mehr Funktionen, ist leistungsfähiger, etc., aber es kann schnell außer Kontrolle geraten. Wenn Sie und Ihre Entwickler die Disziplin haben, die NAnt-Skripte einfach zu halten, dann ist alles in Ordnung. Ich habe jedoch gesehen, dass zu viele NAnt-basierte Systeme nach Süden gehen, wo niemand mehr versteht, was es tut, und es gibt keine echte Möglichkeit, es zu debuggen, abgesehen davon, dass es das Äquivalent eines guten alten Drucks ist. In dem Moment, in dem du anfängst, irgendeine if/else-Anweisung oder for-Schleife zu verwenden, beginnt es, IMHO, zu riechen.

Auf der anderen Seite hat MSBuild eine solide Grundlage basierend auf Metadaten und eine weniger wortreiche Syntax. Seine Einfachheit (oder das Fehlen von Features ... abhängig davon, wie Sie es sehen) zwingt Sie, Logik in .NET-Code über neue Aufgaben zu schreiben, anstatt Logik in XML-Markup zu schreiben. Dies fördert die Wiederverwendbarkeit und ermöglicht Ihnen vor allem, Ihr Build-System in einem echten Debugger zu debuggen.

Das einzige Problem mit MSBuild ist der nicht-gelegentliche Fehler (vor allem in der ersten Version) oder obskuren (obwohl dokumentiert) Verhalten. Und wenn Sie das wirklich stört, ist es mit Microsoft verbunden.

Answer 17

Ich wechselte von NANT zu MSBuild. Das Projekt läuft in .Net 4.0.

Meine Erfahrung in Nant war gut. Das Projekt ist gestorben. Und als .Net 4.0 kam, war es an der Zeit, den Build-Prozess erneut zu evaluieren.

Seit Nant wurde zuletzt veröffentlicht MSBuild ist Wege gekommen. An diesem Punkt ist MSBuild der richtige Weg. Es ist einfach zu bedienen, hat viele Erweiterungen. Ich schrieb meine Nant-Skripte in anderthalb Tagen um. Das MSBuild-Skript ist 1/3 der Größe der Nant-Skripte.

Ein Großteil der Arbeit im Nant-Skript war die Einrichtung der verschiedenen Umgebungen. In MsBuild/.Net 4.0 ist es eingebaut.

Answer 18

Ich benutze Nant und ich liebe es.Früher habe ich MSBuild und hasste es, weil von diesen:

1. Microsoft zwingt Sie ihre eigenen Build-Prozedur zu folgen, die ihre Taten so eigen ist, dass ich zumindest nicht in der Lage war, damit es funktioniert (ich hatte NET1 zu kompilieren .1 also musste ich Nant und MSbuild mischen). Ich weiß, dass Sie Ihre eigene MSBuild-Datei erstellen können, aber ich dachte, es sei komplex zu verstehen und zu warten.

2. ItemTypes zu Dateioperationen sind einfach zu schwer zu folgen. Du kannst Nant genau die gleichen Dinge machen lassen und viel einfacher und direkter (ich musste eine ItemType-Liste erstellen und dann zu den Dateioperationen übergehen).

3. In MsBuild müssen Sie Ihre eigene Task-DLL erstellen, in Nant können Sie dies tun oder Sie können C# -Code in Ihr Skript einbetten, so dass es viel einfacher ist, das ganze Projekt zu entwickeln.

4. Nant arbeitet mit Net1.1, MsBuild nicht.

5. Um Nant zu installieren, kann ich sogar entpacken und in meinem eigenen Repository suchen, um es auszuführen. Das Installieren von MsBuild ist viel schwieriger, da es von vielen Dingen aus Visual Studio usw. abhängt (vielleicht liege ich hier falsch, aber das scheint die Wahrheit zu sein).

Nun sind meine Meinungen ...