Ich habe die vorherigen Fragen und Antworten gesehen. In dieser einen Frage stellte das ursprüngliche Poster eine Folgefrage:
Was sind die zwingenden Gründe für die Verwendung von Msbuild? Gibt es Nachteile?
Ich habe die Antwort darauf nicht gesehen. Ich würde gerne auch das Gegenteil wissen. Was sind die zwingenden Eigenschaften von Nant?
Ich denke, für nant ist Cross-Plattform groß. Für Msbuild ist es die Währung und die Integration mit Visual Studio. Klingt das richtig? Sonst noch etwas?
BEARBEITEN / HINZUGEFÜGT : Hat jemand einen Vergleich der Funktionslisten? Jemand sagte, "Nant hat mehr Funktionen aus der Box." Welche?
Wäre es sinnvoll, diese Projekte zu kombinieren, Anstrengungen zu kombinieren, um gegenseitig zu profitieren? Hat jemand MS gefragt, ob er bereit wäre, msbuild wie WiX in die Community einzubringen? Wie stehen die Chancen?
EDIT2 : Ich habe gerade diese vorherige Diskussion , nicht sicher, warum ich es vorher nicht finden konnte.
Nant verfügt standardmäßig über mehr Funktionen, aber MSBuild hat eine viel bessere grundlegende Struktur (Element-Metadaten rockt), was die Erstellung wiederverwendbarer MSBuild-Skripte erheblich erleichtert.
MSBuild braucht eine Weile, um es zu verstehen, aber sobald Sie es tun, ist es sehr nett.
Lernmaterialien:
Sie würden weiterhin nant verwenden, weil Sie es bereits verwenden. Wenn Sie msbuild verwenden und wissen wollten, warum Sie zu nant wechseln würden, dann gibt es keinen Grund für einen Wechsel. Zumindest wissen Sie, dass msbuild nicht geht, nant wurde seit Dezember 2007 nicht mehr aktualisiert.
Wenn man bedenkt, dass NAnt auf Ant für Java basiert, könnte es Grund genug sein, dabei zu bleiben. Andere Build - Tools basieren auf Ant - Phing ist ein, für PHP. Als ich anfing, dieses Werkzeug zu benutzen, nahm ich es in kürzester Zeit auf, da ich mit NAnt bereits vertraut war.
Ich finde einfach, dass NAnt einfacher zu benutzen ist. Ich wage zu behaupten, dass dies teilweise auf meinen Hintergrund in Ant zurückzuführen ist, aber ich fand, dass das Erstellen einer NAnt-Datei für Protokollpuffer ein viel einfacherer Job ist als das Erstellen einer MSBuild-Datei für MiscUtil. (Selbst jetzt gibt es Dinge im MiscUtil-Build, die ich gerne hinzufügen würde, aber nicht - es erscheint lächerlich schwer, die Ausgabe einer Aufgabe in eine Textdatei, IIRC, zu schreiben.) Die Konzepte sind einfacher und scheinen es zu geben Es sind weniger Fehler bei der Auswertung von Dateisammlungen etc.
Ich benutze derzeit gerne ein Setup, von dem ich bisher dachte, dass es wirklich albern ist - ich benutze NAnt für meine "Haupt" Build-Datei, aber rufe MSBuild auf, um den eigentlichen "Kompiliere mein .NET Projekt" Schritt auszuführen. Die Idee, zwei Build-Systeme für ein und dasselbe Projekt zu haben, ist abscheulich, aber ich behandle den MSBuild-Teil im Grunde nicht als vollständiges Build-System - es ist nur eine einfache Methode zum Kompilieren, und ich muss die Projektdatei nie manuell untersuchen. (Ich interagiere nur über Visual Studio mit ihm.) Ich konnte meine Protocol Buffers sehr einfach auf diese Weise entwickeln, und ich bezweifle, dass ich dieselbe Erfahrung gemacht hätte, wenn ich MSBuild benutzt hätte.
Bald werde ich versuchen, alles mit Mono zu bauen (wenn 2.4 veröffentlicht wird - bis dahin gibt es showstopper in gmcs), an diesem Punkt werden wir sehen, wie tragbar die Strategie ist ...
Wir verwenden einen hybriden Ansatz, weil wir mit NANT begonnen haben, bevor MS-Build verfügbar war. MS-Build cna tut jedoch parallel Buids in Projekten, die nicht abhängig sind, die unter den richtigen Umständen Ihre Build-Zeiten signifikant reduzieren können. NANT lässt sich nicht mit SVN interagieren, Deployment und nur mit MS-Build kompilieren wir unsere Build-Zeiten um ca. 45% YMMV, je nachdem, wie du deine SLN strukturierst.
Einige Punkte, die mir einfallen:
Wo ich arbeite, verwenden wir derzeit NAnt-Skripte mit msbuild -Task von NAntContrib.