it-swarm.com.de

NAnt oder MSBuild, welches soll ich wählen und wann?

Ich bin mir bewusst, dass es andere NAnt und MSBuild verwandte Fragen zu Stack Overflow gibt, aber ich konnte keinen direkten Vergleich zwischen den beiden finden und daher ist hier die Frage.

Wann sollte man NAnt vor MSBuild wählen? Welches ist besser für was? Ist NAnt besser für Home/Open Source-Projekte und MSBuild für Arbeitsprojekte geeignet? Was ist die Erfahrung mit einem der beiden?

159
Yordan Pavlov

Ich habe diese Woche eine ähnliche Untersuchung durchgeführt. Folgendes konnte ich feststellen:

NAnt:

  • Plattformübergreifend (unterstützt Linux/Mono). Dies kann nützlich sein, um eine Website auf mehreren Zielen (z. B. Linux Apache und Windows IIS) zu installieren.
  • 95% ähnlich in der Syntax zu Ant (einfach für aktuelle Ant-Benutzer oder Java Builder zu holen)
  • Integration mit NUnit zur Ausführung von Komponententests als Teil des Builds und mit NDoc zur Produktdokumentation.

MSBuild:

  • In .NET integriert.
  • Integriert in Visual Studio
  • Einfacher Einstieg in MSBuild in Visual Studio - alles hinter den Kulissen. Wenn Sie tiefer gehen möchten, können Sie die Dateien von Hand bearbeiten.

Subjektive Unterschiede: (YMMV)

  • Die NAnt-Dokumentation ist etwas unkomplizierter. In MSBuild Task Reference wird beispielsweise "Csc Task - Beschreibt die Csc-Task und ihre Parameter." (Danke für die "Hilfe"?) Im Vergleich zu NAnt Task Reference "csc - Kompiliert C # -Programme." UPDATE: Mir ist aufgefallen, dass MSBuild-Dokumentation verbessert wurde und viel besser ist jetzt (wahrscheinlich auf dem Niveau von NAnt).
  • Es ist nicht einfach herauszufinden, wie die Build-Skript-Quelle (*. * Proj-Datei) direkt in Visual Studio bearbeitet werden kann. Mit NAnt muss Visual Studio das .build-Skript nur als XML-Datei behandeln.
  • Offensichtlich erhalten Webanwendungsprojekte in Visual Studio standardmäßig keine *. * -Proj-Datei. Daher hatte ich große Schwierigkeiten herauszufinden, wie MSBuild zum Erstellen eines Bereitstellungsskripts auf meinen ausgeführt werden kann.
  • NAnt ist nicht in Visual Studio integriert und muss entweder mit einem Add-In oder als "externes Tool" hinzugefügt werden. Dies ist ein bisschen mühsam einzurichten.
  • (Bearbeiten :) Einer meiner Kollegen hat dies angesprochen - wenn Sie eine Build-Maschine mit CruiseControl für die kontinuierliche Integration einrichten möchten, integriert sich CruiseControl sofort in NAnt. UPDATE: CruiseControl hat auch eine MSBuild-Aufgabe .
  • Eine vollständige und aktuelle Diskussion der subjektiven Unterschiede finden Sie in den Kommentaren unten.
96
Ogre Psalm33

Eine der Hauptattraktionen von MSBuild für mich (auf Windows-Plattformen) ist, dass es Teil von .NET selbst ist. Das bedeutet, dass auf jedem Windows-Computer, der mit Windows Update auf dem neuesten Stand ist, MSBuild verfügbar ist. Hinzu kommt, dass der C # -Compiler auch Teil von .NET selbst ist und Sie über eine Plattform verfügen, die Projekte auf sauberen Computern erstellen kann. Sie müssen Visual Studio Behemoth nicht installieren. NAnt muss dagegen explizit installiert werden, bevor ein Build ausgelöst werden kann.

Ich habe NMake, Make, Ant, Rake, NAnt und MSBuild in der Vergangenheit für nicht-triviale Builds verwendet (in dieser Reihenfolge). Mein Favorit ist zweifellos MSBuild (und ich bevorzuge es nicht, weil "das ist, was Visual Studio verwendet"). IMHO, es ist ein sehr wenig geschätztes Build-Tool.

Ich würde NAnt vs. MSBuild mit dem Unterschied zwischen prozeduraler und funktionaler Programmierung vergleichen. NAnt ist recht unkompliziert und Sie bekommen, was Sie sehen. MSBuild erfordert dagegen ein wenig mehr Nachdenken. Die Lernkurve ist steiler. Aber sobald Sie es "bekommen", können Sie einige erstaunliche Dinge damit machen.

Daher würde ich MSBuild empfehlen, wenn Sie sich auch für funktionale oder logische Stilprogrammierung interessieren - wenn Sie bereit sind, ein wenig Zeit und Mühe zu investieren, bevor Sie konkrete Ergebnisse sehen (natürlich bin ich auch der festen Überzeugung, dass sich die Investition letztendlich auszahlt und Sie leistungsfähigere Dinge effizienter machen können).

77
Milan Gardian

Persönlich benutze ich beide - für das gleiche Projekt.

MSBuild eignet sich hervorragend zum Erstellen von Visual Studio-Lösungen und -Projekten.

NAnt ist meiner Meinung nach leichter von Hand zu bearbeiten - insbesondere, wenn Sie Ant bereits kennen. NAnt kann MSBuild sehr einfach mit NAntContrib aufrufen. Also erstelle ich ein NAnt-Skript von Hand, um beispielsweise erstellte Dateien zu kopieren, zu bereinigen usw. - und rufe MSBuild auf, um den eigentlichen Teil "Meinen C # -Quellcode in Assemblys umwandeln" durchzuführen.

Wenn Sie ein Beispiel dafür wollen, schauen Sie sich meine Protocol Buffers build file an. (Ich würde nicht behaupten, dass es ein fabelhaftes NAnt-Skript ist, aber es macht den Job.)

44
Jon Skeet

NAnt hat mehr Funktionen als erwartet, aber MSBuild hat viel zu bieten Bessere Grundstruktur (Item Metadata Rocks), die das Erstellen von wiederverwendbaren MSBuild-Skripten erheblich vereinfacht.

MSBuild braucht eine Weile, um zu verstehen, aber wenn Sie dies tun, ist es sehr schön.

Lernmaterialien:

20

KISS = Verwende MSBuild.

Warum etwas anderes in die Mischung aufnehmen, wenn Sie etwas haben, das einen vernünftigen Job sofort erledigt? Als MSBuild ankam, starb NAnt. Und Mono wird eine MSBuild-Implementierung haben, ( xbuild ).

TROCKEN = Verwende MSBuild.

Fragen Sie sich, was Sie von einem Build-System erwarten. Ich möchte ein Build-System, das auch von meinem IDE verwendet wird, anstatt zwei verschiedene Konfigurationen beizubehalten.

Persönlich würde ich gerne einige echte Argumente für NAnt hören, weil ich mir einfach keine vorstellen kann, die wirklich Wasser halten.

19
Squirrel

Ich bemerkte, dass auf mehreren Postern erwähnt wurde, dass die .csproj-Dateien (oder .vbproj-Dateien usw.) von Hand bearbeitet werden mussten.

MSBuild ermöglicht die Anpassung dieser. * Proj-Dateien mithilfe von .user-Dateien. Wenn ich ein Projekt mit dem Namen MyCreativelyNamedProject.csproj habe und die darin enthaltenen MSBuild-Aufgaben anpassen möchte, kann ich eine Datei mit dem Namen MyCreativelyNamedProject.csproj.user erstellen und verwenden Sie CustomBeforeMicrosoftCommonTargets und CustomAfterMicrosoftCommonTargets, um diese Dateien anzupassen.

Außerdem können sowohl NAnt als auch MSBuild durch benutzerdefinierte MSBuild-Aufgaben und durch NantContrib-Erweiterungen an den Inhalt des Herzens angepasst werden.

Bei der Verwendung von NAnt oder MSBuild kommt es also auf die Vertrautheit an:

  • Wenn Sie bereits mit Ant vertraut sind, verwenden Sie NAnt. Die Lernkurve wird sehr einfach sein.
  • Wenn Sie mit keinem der Tools vertraut sind, ist MSBuild bereits in Visual Studio integriert und erfordert keine zusätzlichen Tools.

Es ist auch erwähnenswert, dass MSBuild so gut wie garantiert mit allen neuen Versionen von . NET und Visual Studio zusammenarbeitet, sobald sie veröffentlicht werden, während NAnt möglicherweise eine gewisse Verzögerung aufweist.

14
Clever Human

Ich benutze beides, indem meine NAnt Skripte MSBuild aufrufen. Mein Hauptgrund, bei NAnt zu bleiben, ist die Isolation . Lassen Sie mich erklären, warum ich das für wichtig halte:

  1. Abhängigkeiten zu Ihrem Projekt hinzufügen. Die NAnt-Erstellungsdatei ist Visual Studio fremd (in meinem Fall halte ich dies für einen Profi), sodass Visual Studio nicht versucht, etwas damit zu tun. MSBuild-Aufgaben sind Teil der Lösung und können auf andere MSBuild-Aufgaben verweisen. Ich habe Quellcode von einer anderen Person erhalten, um herauszufinden, dass ich ihn nicht erstellen konnte, da die MSBuild-Community-Aufgaben nicht installiert wurden. Was ich besonders frustrierend finde, ist, dass Visual Studio einfach keine Fehler erzeugt und geworfen hat, die mich Zeit für das Debuggen verloren haben. Dies trotz der Tatsache, dass der angeforderte Build (beispielsweise als Debug-Build) ohne einige der Extras der MSBuild-Task hätte ausgeführt werden können. Kurz gesagt: Ich mag es nicht, meinem Projekt Abhängigkeiten hinzuzufügen, wenn ich das vermeiden kann.

  2. Ich vertraue Visual Studio nicht, soweit ich das Entwicklerteam dazu bringen kann. Dies geht auf die Anfänge von Visual Studio zurück, als es mein HTML massakrieren würde. Ich benutze den Designer zum Beispiel immer noch nicht (auf einer Konferenz habe ich kürzlich festgestellt, dass Kollegen dasselbe getan haben). Ich habe festgestellt, dass Visual Studio Abhängigkeiten und Versionsnummern in der DLL Datei vermasseln kann (ich kann dies nicht replizieren, aber es ist in einem Projekt konsistent passiert und hat viel Kummer und verlorene Zeit verursacht) Ich habe auf eine Erstellungsprozedur zurückgegriffen, die Visual Studio verwendet, um nur im Debug-Modus zu erstellen. Für die Produktion verwende ich NAnt, um alles extern zu steuern . Visual Studio kann einfach nicht mehr stören, wenn ich mit NAnt erstelle.

PS: Ich bin ein Webentwickler und entwickle kein Windows Forms.

10
Peter Donker

Obwohl ich mit MsBuild nicht sehr vertraut bin, habe ich den Eindruck, dass einige der wichtigsten Unterschiede auf beiden Seiten durch Ergänzungen ergänzt werden können:

Ich musste kürzlich ein Silverlight-Projekt in Nant erstellen. Ich stellte fest, dass das Leben einfacher wäre, wenn ich dies nur mit MsBuild tun würde. Am Ende habe ich eine MsBuild-Aufgabe aus einem Nant-Skript heraus aufgerufen.

Darüber hinaus wird es wahrscheinlich eine Frage der persönlichen Vorlieben sein - offensichtlich können Sie einige/die meisten der Funktionen von MsBuild in Visual Studio verwalten, wenn dies Ihre Sache ist. Nant scheint flexibler und besser geeignet zu sein, wenn Sie es vorziehen, Skripte von Hand zu schreiben, und wenn Sie aus der Java) - Welt kommen, sind Sie hier wahrscheinlich genau richtig.

6
mmacaulay

Am Ende habe ich beides benutzt. Bei der Neugestaltung unseres Buildsystems stand ich vor einem kniffligen Problem. Ich konnte nämlich .vcproj (und die Familie) nicht loswerden, weil wir alle VS verwendeten, um die Projektdateien, Einstellungen und Konfigurationen zu aktualisieren. Daher könnten wir unser Build-System nicht auf einem neuen Satz von Dateien aufbauen, ohne dass ein riesiger Duplizierungs- und fehleranfälliger Prozess stattfindet.

Aus diesem Grund habe ich beschlossen, die 'proj'-Dateien von VS beizubehalten und MSBuild zu verwenden (es handelt sich um MSBuild-Dateien, mindestens VS2005 und VS2008 verwenden MSBuild-Projektdateien). Für alles andere (benutzerdefinierte Konfiguration, Komponententests, Verpackung, Vorbereitung der Dokumentation ...) habe ich NAnt verwendet.

Für die kontinuierliche Integration habe ich CruiseControl verwendet. Wir hatten also CC-Skripte, die NAnt-Jobs auslösten und zum Erstellen MSBuild verwendeten.

Ein letzter Hinweis: MSBuild unterstützt KEINE Setup-Projekte! Sie müssen also nicht mehr DevEnv.com aufrufen oder Visual Studio direkt verwenden. Das ist, was ich getan habe, aber ich habe das Setup-Projekt standardmäßig in allen Lösungskonfigurationen deaktiviert, da Entwickler sie normalerweise nicht erstellen müssten und sie sie dann manuell erstellen können.

2
Ash

Die für NAnt verfügbaren Dokumentationen und Tutorials erleichtern den Einstieg in das Erstellen von Skripten mit NAnt. Nachdem ich NAnt kennengelernt und Build-Skripte erstellt hatte, begann ich, dieses Wissen in MSBuild zu übersetzen (ich habe X in NAnt gemacht, wie mache ich X in MSBuild?). Die Dokumentation von Microsoft setzt normalerweise ein ziemlich hohes Maß an Wissen voraus, bevor es nützlich ist.

Der Grund für den Wechsel von NAnt zu MSBuild ist, dass MSBuild aktueller ist. Leider war die letzte Veröffentlichung von NAnt am 8. Dezember 2007, während MSBuild 4.0 (.NET 4.0) nicht mehr weit ist. Es sieht so aus, als wäre das NAnt-Projekt gestorben.

Wenn Sie eine gute Dokumentation für jemanden finden, der gerade erst mit dem Erstellen von Erstellungsskripten mit MSBuild beginnt, überspringen Sie NAnt und gehen Sie direkt zu MSBuild. Wenn NAnt jemals eine neue Veröffentlichung herausbringt, würde ich überlegen, bei NAnt zu bleiben, aber sie hinken jetzt hinterher.

1
mcdon

Wir verwenden FlubuCore. Es ist eine Open-Source-C # -Bibliothek zum Erstellen von Projekten und Ausführen von Bereitstellungsskripten mit C # -Code.

Einfaches Beispiel für die Verwendung von flubu:

protected override void ConfigureTargets(ITaskContext session)
{           

    var compile = session.CreateTarget("compile")
        .SetDescription("Compiles the solution.")
        .AddTask(x => x.CompileSolutionTask())
        .DependsOn("generate.commonassinfo");
}

Weitere Informationen zu flubu und zu den ersten Schritten finden Sie hier: Auswahl-für-Build-Tool-msbuild-nant-or-something-else

0
Stan88

YDeliver von Manoj ist ein Build-Framework, das auf PSake basiert. Es verfügt über zahlreiche Bibliotheksfunktionen und die Möglichkeit, Workflows zu definieren. Wir haben es verwendet, um über sechs Unternehmensprojekte für die Produktion bereitzustellen.

Verwenden Sie es in Verbindung mit TeamCity , CruiseControl oder allem, was PowerShell ausführen kann.

0
Zasz

Wir benutzen beide. NAnt ist für alle "Scripting" -Inhalte verantwortlich, wie Kopieren, Bereitstellen auf IST , Erstellen von Paketen und MSBuild ist für die Erstellung der Lösung verantwortlich. Dann können wir Probleme mit nicht unterstütztem .NET 4.0 durch eine neue Version von NAnt vermeiden.

NAnt ist auch skalierbarer. Wenn wir die Bereitstellungsskripten auf Produktionsserver migrieren möchten, kopieren wir nur die Build-Datei und installieren eine richtige Version von .NET - keine Visual Studio-Probleme mit csproj-Dateien :)

0