Sollte ich von nant zu msbuild?

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

Frage

Ich verwende derzeit nant, ccnet (Tempomat), svn, mbunit.Ich verwende msbuild, um meinen sln bauen, nur weil es einfacher zu berappen.

Gibt es irgendwelche Verdienste um die Umstellung meiner gesamten build-Skript MSBuild?Ich muss in der Lage sein, tests, watir-style-tests, die xcopy-Bereitstellung.Ist das einfacher?

Update:Alle überzeugende features, die dazu führen würde, dass mir der übergang von nant zu msbuild?

War es hilfreich?

Lösung

Ich mag MSBuild.Ein Grund dafür ist, dass .csproj-Dateien sind msbuild-Dateien, und die Gebäude in der VS ist nur, wie die Gebäude in der Befehlszeile.Ein weiterer Grund ist die gute Unterstützung von TeamCity, die der CI-server, die ich benutzt habe.Wenn Sie beginnen mit MSBuild erstellt wird, und Sie mehr tun wollen benutzerdefinierte die Dinge in Ihrem build-Prozess, erhalten die MSBuild Community-Aufgaben.Sie geben Ihnen ein paar nette extra-Aufgaben.Ich habe nicht verwendet NAnt für mehrere Jahre jetzt, und ich habe nicht bereut es.

Auch, als Ruben erwähnt, gibt es die DEZA Tasks Aufgaben auf CodePlex.

Für noch mehr Spaß macht, gibt es die MSBuild Extension Pack auf CodePlex, beinhaltet einen twitter Aufgabe.

Andere Tipps

Mein Rat ist genau das Gegenteil - Vermeiden MSBuild wie die Pest.NANT ist weitaus einfacher, um Ihre zu bauen, um automatische Tests, die Bereitstellung auf mehreren Produktionsumgebungen, die Integration mit cruisecontrol für einen Eintrag Umwelt, Integration mit source-control.Wir haben schon so viel durchgemacht Schmerzen, die mit TFS/MSBuild (Mit TFSDeployer, benutzerdefinierte powershell-Skripts, etc), es zu bekommen zu tun, was wir waren in der Lage, mit NANT out of the box.Verschwenden Sie nicht Ihre Zeit.

Der überzeugendste Grund für die Verwendung von MSBuild (zumindest in .NET 3.5 und darüber hinaus) - die build-engine aufbauen kann, gleichzeitig.

Das bedeutet eine enorme Geschwindigkeit bis in Ihre builds in mehreren Kernen/Prozessoren.

Vorherige 3.5 MSBuild nicht parallel baut.

Ich fühle, dass MSBuild und Nant sind ziemlich vergleichbar.Wenn Sie mit einem von diesen, habe ich im Allgemeinen wäre nicht zwischen Ihnen wechseln, es sei denn, es wurde eine überzeugende Funktion, die fehlt in dem Produkt, das Sie ausgewählt hatte.

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

Hoffe, das hilft!

Edit: @ChanChan - @Jon erwähnt, dass Nant nicht bauen .NET 3.5-Anwendungen.Dies kann Grund genug, zu verändern, oder zumindest parallel.Als ich umgezogen mehr auf MSBuild, ich bin wahrscheinlich nicht die am besten informierte person zu markieren, alle anderen Showstopper mit entweder-Technologie.

Edit: Es erscheint Nant baut jetzt .NET 3.5-Anwendungen.

NAnt hat es schon länger und ist deutlich mehr ausgereift und auch IMO einfacher zu bedienen.Es gibt eine Menge von community-know-how gibt, zu erschließen, und es ist auch cross-Plattform, sofern Sie Interesse an der Erstellung von apps ausgeführt werden können, ist unter Mono-als auch als .NET und Silverlight.Aus der box, es hat eine ganze Menge mehr als MSBuild hat.Oh ja, und Sie können aufrufen von MSBuild von NAnt (OK, von NAntContrib) :-)

Auf der negativen Seite, NAnt und seine Schwester-Projekt NAntContrib scheinen zu stagnieren, mit dem jüngsten update wird Ende 2007.

Die wichtigsten Vorteile, die ich sehe, von MSBuild ist, dass es Schiffe mit .NET Framework, so es ist weniger ein Produkt zu installieren;und es gibt mehr aktive Entwicklung geht auf (wenn auch in Orte, um aufzuholen mit den älteren NAnt).

Ich persönlich finde die syntax ein wenig schwieriger zu Holen, aber dann bin ich sicher, weiterhin Exposition gegenüber ti würde die Dinge einfacher.

Fazit?Wenn Sie das arbeiten mit vorhandenen NAnt-Skripte, bei Ihnen zu bleiben, es ist nicht der Mühe Wert zu portieren.Wenn Sie ein neues Projekt beginnen, und Sie sind abenteuerlustig, dann geben MSBuild ein zu gehen.

Wir auch umgestellt von nant zu msbuild.Wenn Ihr zu bauen, ist ziemlich standard, so dass Sie nicht haben viel Probleme bei der Einrichtung, aber wenn Sie eine Menge von spezifischen build-Aufgaben, die Sie haben, um zu schreiben custom ms-build-Aufgaben, als es viel weniger benutzerdefinierte tasks for msbuild.

Wenn Sie möchten, um display vernünftig bauen, können Sie die Ergebnisse haben zu Chaos mit benutzerdefinierten Logger etc.Das ganze team zu bauen, ist nicht so reif wie nant ist.

Aber der wirkliche Vorteil ist die integration mit TFS source control und reporting services.Wenn Sie sind nicht mit TFS als Ihre Quelle, control system, es lohnt sich nicht.

  • Nicht schalten, es sei denn, Sie haben einen sehr überzeugenden Grund (mindestens).
  • NAnt ist open source, und wenn es nicht ich wäre nicht in der Lage zu passen unsere build-system, MSBuild nicht.
  • NAnt können leicht ausführen von MSBuild, ich bin nicht sicher, über die andere Weise herum.
  • MSBuild-Skripte sind bereits für Sie geschrieben, wenn Sie VS2005 oder neuer (für die Projekt-Dateien sind MSBuild-Dateien.)
  • Wenn Sie NAnt, und Sie VS zu Bearbeiten, Projekt-Dateien, Einstellungen und Konfigurationen, Sie müssen schreiben Sie einen Konverter/sync-tool zu aktualisieren Sie Ihre NAnt-Dateien aus dem VS-Projekt-Dateien.

@Brad Leach

Ich generell würde nicht zwischen Ihnen wechseln, es sei denn, es wurde eine überzeugende Funktion, die fehlte

was sind überzeugende Gründe für die Verwendung von msbuild?gibt es Nachteile?

Bisher bin ich immer ein ziemlich guter, Nein "nicht stören" von deiner Antwort.

Ich denke, Sie sind relativ vergleichbar, sowohl in Funktionen und Benutzerfreundlichkeit.Nur von C# - basierten finde ich msbuild einfacher zu arbeiten mit als nants, obwohl das kaum einen zwingenden Grund zu wechseln.

Was genau ist nant nicht tun für Sie?Oder sind Sie einfach nur in der Hoffnung es gibt einige Coole Funktion, die Sie möglicherweise verpassen?:)

Eine super-nette Sache über C# ist, dass wenn man die .net framework haben Sie alles, was Sie brauchen, um ausführen von msbuild.Dies ist fantastisch, wenn Sie arbeiten große teams und Projekte und Menschen - /hardware-Umsatz.

Persönlich bevorzuge ich SCons über beide :)

Der Hauptgrund, warum ich immer noch verwenden nAnt über msbuild für meine automatisierte builds ist, dass ich mehr granulare Kontrolle über mein baut.Aufgrund msbuild mit der csproj hat, es ist build-Datei der Quelle in das Projekt kompiliert ist in einer assembly.Das verursacht mir viele Projekte in meiner Lösung für große Projekte, wo ich die Trennung der Logik.Auch mit nant, ich arrangieren mein build, wo ich kompilieren kann, was ich möchte, in mehrere Baugruppen aus einem Projekt.

Ich mag diese Strecke, denn es hält mich davon ab, zu viele Projekt-Dateien in meiner Lösung.Kann ich haben eine Projekt mit Ordner splitten sich die Schichten und verwenden Sie dann nant zu bauen, wird jede Ebene in die eigene Montage.

Jedoch, ich verwende beide nant und msbuild in Verbindung für einige build-Aufgaben, wie das erstellen von WPF-Anwendungen.Es ist nur viel einfacher zu kompilieren, eine WPF-Anwendung mit der msbuild-Ziel innerhalb von nant.

Zu Ende dieses und der Punkt, der meine Antwort ist, dass ich mag zu verwenden, Sie Seite an Seite, aber wenn ich msbuild in dieser Konfiguration ist es in der Regel für gerade zusammenstellen, nicht auf der Bühne jede build-Automatisierung von Aufgaben wie das kopieren von Dateien in ein Verzeichnis, Erstellung der Dokumentation, oder laufen meine unit-tests zum Beispiel.

Eigentlich bin ich immer noch versuchte, diese Frage selbst, aber es gibt einen großen bonus für MSBuild hier:mit der gleichen build-Datei für die lokale kontinuierliche integration durch den Aufruf msbuild.exe direkt, während auch in der Lage, verwenden VSTS ' s server-side-continuous integration mit der gleichen build-Datei (wenn auch wahrscheinlich unterschiedliche Eigenschaften/Einstellungen).

d.h.im Vergleich zu TeamCity Unterstützung für MSBuild-Skripts, VSTS nur unterstützt MSBuild-Skripte!Ich habe es gehackt, um dieses in der Vergangenheit von exec ' Ing NAnt von MSBuild;Ich habe andere gesehen, die empfehlen, diese Praxis als auch die Rückseite, aber es scheint nur kludgey zu mir, also ich versuche, es nicht zu tun, wenn ich es vermeiden kann.So, wenn Sie mit "the full Microsoft stack" (VSTS und TFS), würde ich vorschlagen, nur kleben mit MSBuild-Skripte.

Nant hat mehr Funktionen out of the box, aber MSBuild hat eine viel bessere grundlegenden Struktur (Element Metadaten Felsen), die macht es viel einfacher zu erstellen, wiederverwendbare MSBuild-Skripte.

MSBuild dauert eine Weile, um zu verstehen, aber sobald Sie tun, es ist sehr schön.

Lernmaterialien:

Ich sehe keinen Grund, zu wechseln.MsBuild selbst sperrt Sie in die Rahmen, die Sie verwenden.Wenn Sie NAnt, können Sie ihn über viele frameworks und shell aus, um msbuild, um tatsächlich die Bau-Aufgabe für Sie.

Ich bin ein fan von NAnt in dieser Hinsicht, denn es entkoppelt Sie von den Rahmen ein wenig.

Ich habe einen Rahmen geschaffen, stellt Konventionen in automatisierten builds und ich baute es auf NAnt.Es heißt UppercuT und es ist wahnsinnig einfach zu bedienen Build Framework.

Automatisierte Builds so einfach wie (1) Lösung name, (2) die source-control-Pfad (3) name der Firma, die für die meisten Projekte!

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

Einige gute Erklärungen hier: UppercuT

MSBuild integriert mit Visual Studio können Programmierer, die weniger Reibung zur Nutzung der build-system.Es kommt vor allem nach unten, um Sie nur gehen, "Projektmappe Erstellen" und es funktioniert alles, im Vergleich mit Benutzerdefinierte Build-Schritte und andere solche Dinge, oder, noch schlimmer, zwingt die Entwickler zu bauen, durch die Einführung eine Art von externen Skript.

Nun, ich meistens bevorzugen MSBuild über NAnt, weil es einfacher ist.Sicher, NAnt hat viel mehr Funktionen, mehr leistungsstarke, etc., aber es kann schnell aus der hand.Wenn Sie und Ihre Ingenieure bauen die Disziplin zu halten, die NAnt-Skripte einfach, dann ist alles gut.Jedoch, ich habe gesehen, zu viele NAnt-basierten Systemen nach Süden gehen zu einem Punkt, wo niemand versteht, was er tut mehr, und es gibt keine echte Möglichkeit zu Debuggen, neben der das äquivalent von eine gute ol' printf.Der moment, in dem Sie beginnen, über etwas, wenn/else-Anweisung oder eine for-Schleife, dort, wo IMHO, es beginnt zu riechen.

Auf der anderen Seite, MSBuild hat eine solide Basis auf der Grundlage von Metadaten und eine weniger ausführliche syntax.Seine Einfachheit (oder das fehlen von Funktionen...je nachdem, wie Sie es sehen) zwingt Sie zu schreiben, Logik .NET-code über neue Aufgaben, statt zu schreiben Logik in XML-markup.Dies fördert die re-usability und vor allen Dingen, können Sie tatsächlich Debuggen build-system in einen echten debugger.

Das einzige problem mit MSBuild ist die nicht-so-gelegentliche Fehler (vor allem in der ersten version) oder zu verschleiern, (obwohl dokumentiert) Verhalten.Und, wenn das ist die Art von Sache, die wirklich stört Sie an Microsoft.

Ich wechselte von NANT zu MSBuild.Das Projekt ausgeführt wird .Net 4.0.

Meine Erfahrung in Nant war gut.Das Projekt Art gestorben.Und wenn .Net 4.0 auf den Markt kam, war es an der Zeit neu zu bewerten, die bauen Prozess.

Seit Nant wurde zuletzt veröffentlicht MSBuild hat sich entlang der Wege.An diesem Punkt, MSBuild ist der Weg zu gehen.Es ist einfach zu bedienen, hat viele Erweiterungen.Ich schrieb meine Nant-Skripte in einem Tag und eine Hälfte.Die MSBuild-Skript ist 1/3 der Größe des Nant-Skripte.

Ein Großteil der Arbeit in das Nant-Skript war die Errichtung der verschiedenen Umgebungen.In MsBuild/.Net 4.0 es ist gebaut-in.

Ich benutze MSBuild neben Nant, weil die aktuelle version von Nant kann nicht, wie noch kompilieren .NET 3.5-Anwendungen (gilt auch, wenn .NET 2.0 kam zuerst heraus).

Der einzige Grund, warum ich sehen kann, für die Verwendung von msbuild ist, wenn Sie möchten, verwenden Sie einen automatisierten build-server wie ein Tempomat.Wenn Sie sind nicht zu wechseln, dann würde ich in Ruhe lassen.

Ich verwende Nant, und ich Liebe es.Ich verwendet MSBuild, und es gehasst, weil diese:

  1. Microsoft zwingt Sie zu Folgen Ihre eigenen build-Verfahren, die so untrennbar mit Ihren Handlungen, dass ich mindestens war nicht in der Lage, damit es funktioniert (ich hatte zu kompilieren NET1.1 so hatte ich zu mischen, Nant und MSbuild).Ich weiß, Sie können erstellen Sie Ihre eigene MSBuild-Datei, aber ich dachte, es war schwierig zu verstehen und zu pflegen.

  2. ItemTypes zu tun, Datei-Operationen sind einfach zu schwer zu Folgen.Sie können Nant tun, die genau die gleichen Dinge, und viel einfacher und direkter (ich hatte zum erstellen einer ItemType Liste und übergeben Sie dann auf die Datei-Operationen).

  3. In MsBuild erstellen Sie Ihren eigenen task-dll, in Nant Sie können dies tun, oder Sie können beim einbetten von C# - code in Ihrem Skript, so dass es viel einfacher zu Voraus und bauen das ganze Projekt.

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

  5. Installieren nant, ich kann auch entpacken, und suchen Sie in meinem repository, um es auszuführen.Installieren MsBuild ist viel schwieriger, da es hängt von vielen Dingen ab Visual Studio, etc.(vielleicht bin ich hier falsch, aber das scheint die Wahrheit zu sein).

Nun, das sind meiner Meinung...

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top