Warum wird Maven in .NET nicht benötigt?

76

Ich habe den Eindruck, dass in der .NET-Welt kein Maven-ähnliches Tool wirklich benötigt wird.

Ich bin mir bewusst, dass es Byldan und NMaven gibt (lebt es noch?), Aber ich habe noch kein reales Projekt gesehen, das sie verwendet.

Auch in den meisten .NET-Projekten, an denen ich gearbeitet habe, wurde nie die Notwendigkeit eines Maven-ähnlichen Tools geäußert. Die Probleme, mit denen sich Maven Maven befasst (automatische Abhängigkeitsauflösung, auf Konventionen basierende Build-Struktur ...), scheinen in .NET nicht so wichtig zu sein.

Ist meine Wahrnehmung richtig?

Warum ist das so?

Was verwenden die Leute wirklich in .NET? Keine automatische Abhängigkeitsauflösung?

Schreiben sie ihre eigenen Build-Tools?

Verwendet jemand Maven selbst, um seine .NET-Projekte zu verwalten? Ist das eine gute Wahl?

Was sind deine Erfahrungen?

jbandi
quelle
Microsoft lernt Mavens Weg. Wenn Sie zu ASP.net 5 gehen, finden Sie dort ähnliche Dinge. Anstelle von ausführlichem XML wird dort die
JSON-
1
@Bargitta: project.json ist jetzt wieder veraltet: xoofx.com/blog/2016/05/11/goodbye-project-json
Janus Troelsen
1
@ JanusTroelsen sie gehen rückwärts
Bargitta

Antworten:

41

Für die Auflösung von Artefaktabhängigkeiten würde ich sagen, dass Nuget jetzt die bevorzugte Alternative ist. Es unterstützt und fördert die Auflösung der Erstellungszeit, dh es müssen keine Artefakte für binäre Abhängigkeiten in vcs eingecheckt werden. Siehe diese Artikel .

Ab Version 2.7 von Nuget wird die Auflösung der Erstellungszeit noch besser unterstützt, wobei der Befehl Nuget-Wiederherstellung eine der Optionen ist.

Update: Es gibt jetzt einen alternativen, Nuget-kompatiblen Paketmanager - Paket , der besser als der Vanilla Nuget-Client darin ist, vorübergehende Abhängigkeiten zu behandeln und Abhängigkeiten zwischen Projekten in derselben Lösung zu harmonisieren. Das Tooling scheint ebenfalls ziemlich ausgereift zu sein (VS-Integration und Befehlszeilen-Tooling für CI)

8DH
quelle
3
Nuget ist der richtige Weg. Kein Zweifel.
BlueM
24

Maven wird von Apache-Projekten angetrieben, die ein zentraler Bestandteil der riesigen Java-Open-Source-Infrastruktur sind. Die weit verbreitete Akzeptanz von Maven muss damit zusammenhängen, und der aktuelle Reifegrad (Qualität) ist ebenfalls sehr gut.

Ich glaube nicht, dass die .NET Open Source-Welt bedeutende Open Source-Akteure hat, die ein solches Konzept durchsetzen könnten. Irgendwie scheint .NET immer auf Redmond zu warten.

Krosenvold
quelle
49
Das liegt daran, dass in der MS-Welt, wenn Sie Ihr eigenes Tool erstellen und es gut ist, die Wahrscheinlichkeit groß ist, dass MS in ein oder zwei Jahren ein solches Tool herausbringt und die Leute Ihr Tool nicht mehr verwenden. (Wie Joel Spolsky es ausdrückte: "Wenn Sie es schaffen, etwas zu schreiben, das sich abhebt, stellen Sie möglicherweise fest, dass Sie lediglich Marktforschung für Microsoft betrieben haben.")
Nate CK
5
@ NateC-K, ist das nicht eine gute Sache? so eine grausame Welt das. Wenn ms solche Dinge nicht tut, gibt es eine Sekte, die sich darüber beschwert, dass sie es nicht tut, und wenn ms tatsächlich angemessene Projekte annimmt und anfängt, Anstrengungen und Ressourcen zu investieren, selbst wenn es lächerlich gemacht wird, ist es nicht das, was die Community braucht, geeignete Werkzeuge Mit diesen Dingen wird das
Entwickler-
10
Wenn ein Open-Source-Projekt ein Tool erstellt hat, das von der Community benötigt wird, ist es nicht erforderlich, dass MS ein gleichwertiges Tool erstellt, um es zu ersetzen. Im schlimmsten Fall handelt es sich um eine Doppelarbeit, die keinen anderen offensichtlichen Zweck hat, als sicherzustellen, dass die MS alles besitzt. Was angemessener ist, ist, dass MS einige bezahlte Entwickler beauftragt, zum Open Source-Projekt beizutragen. Seit ich meinen früheren Kommentar abgegeben habe, hat MS anscheinend ernsthafte Anstrengungen unternommen, um mit der Open-Source-Community besser zu spielen, was ich sehr schätze. Ich hoffe, dass sich die Beziehung in den kommenden Jahren weiter verbessern wird.
Nate CK
Die Dinge haben sich 2016 sicherlich geändert, was das Warten auf Redmond für diese Dinge betrifft (Build-Tools). Wir haben jetzt Dotnet (Core) unter Linux und Nexus 3 unterstützt Nuget. Eine ganz neue Welt.
Nico de Wet
Ich bin mir ziemlich sicher, dass sie Open Source-Projekte normalerweise nicht neu erstellen, sondern unterstützen und verbessern - ähnlich wie Json.Net. Avalonia ist ein weiteres Beispiel
Gilmishal
23

Obwohl die Frage hier alt ist, sind meine Gedanken. Maven ist nicht einfach ein Build-Tool. Es bietet viel mehr als Repository-Management, Projektmanagement, Abhängigkeitsmanagement, Build-Management und so weiter ...

Die Hauptattraktion ist meiner Meinung nach das Abhängigkeitsmanagement. Die JAR-Hölle ist von Anfang an ein großes Problem im Java-Land, und Sie benötigen einige Werkzeuge, um damit fertig zu werden. In der .Net-Welt gibt es kein solches Problem (tatsächlich wurde das Fehlen der DLL-Hölle in den ersten Tagen von .Net als Hauptattraktion beworben), so dass die meisten Leute mit MSBuild gut zurechtkommen. Später gab es aufgrund der Verfügbarkeit vieler Bibliotheken von Drittanbietern Verwaltungsprobleme. Um dieses Problem loszuwerden, haben sie jetzt Nuget.

Kurz gesagt, MsBuild + Nuget ist in der .Net-Welt für den größten Teil des Projekts gut genug, Maven ist für sie einfach übertrieben.

Tinku
quelle
Ich stimme vollkommen zu. Die ursprüngliche Frage stammt aus der Zeit vor der Einführung von NuGet.
Jbandi
14

Ich stimme vielen Antworten hier zu. .NET hatte keine große Anzahl unabhängiger IDEs. Sie haben Visual Studio verwendet, um Ihren Code zu schreiben, Ihre Abhängigkeiten zu verwalten usw. Die Lösung in VS ist gut genug für MSBuild, sodass Sie diese von Ihren Build-Servern verwenden.

Java hingegen hat viele IDEs weiterentwickelt, und Java hat einen Weg eingeschlagen, Projekte außerhalb der IDE zu verwalten. Geben Sie dem Entwickler die Möglichkeit, die IDE seiner Wahl zu verwenden. Ich habe vor kurzem mit dem Cross-Training von C # nach Java begonnen und kann Ihnen sagen, dass das Maven-Build-Konzept ziemlich fremd ist, aber nach einer Weile liebe ich es, und was noch wichtiger ist, ich sehe, was mir das Repo-Konzept bietet.

Wie VS nun verwaltete Abhängigkeiten erfordert, müssen Sie entweder eine Projektreferenz oder eine Referenz zu einer DLL hinzufügen. Das Hinzufügen einer DLL-Referenz ist fehlerhaft. Wie verwalten Sie Versionsänderungen, wie strukturieren Sie DLLs von Drittanbietern aus externen und internen Quellen sowie DLLs, die Sie von Ihrem eigenen Team aufnehmen möchten, jedoch nicht als Projektreferenz. Ich habe viele Workarounds durchgeführt, die im Allgemeinen auf der dateibasierten Verzeichnisstruktur basieren, aber keine davon ist elegant oder großartig, wenn sich die Version ändert. Dies erschwert auch die Verzweigung, da dies eine Überlegung bei der Strukturierung der Verzeichnisse darstellt.

Jetzt habe ich mit Java und öffentlichen Mavan Repos gearbeitet, super cool. Ich habe mit Python gearbeitet und die Pip-Installation wieder effektiv von öffentlichen Repos durchgeführt. Schließlich habe ich mit VS 2015 wieder ein paar Sachen in C # gemacht und die Integration mit Nuget hat genau gefehlt.

Im Unternehmensumfeld sind öffentliche Repos nicht immer direkt zugänglich, sodass Sie Unternehmens-Repos benötigen. Auch hier sind Nicht-Microsoft-Ökosysteme voraus.

Zusammenfassend lässt sich sagen, dass Java aus einer Open-Source-Umgebung hervorgegangen ist, in der die IDE-Projektwartung nicht verwendet wurde, während .NET aus der Verwaltung des Projekts durch Visual Studio hervorgegangen ist. Aufgrund dieser unterschiedlichen Pfade werden Repos später in Visual Studio bereitgestellt.

Schließlich und dies ist meine Beobachtung, tendiert die Java-Community dazu, die Frameworks anderer Leute häufiger zu verwenden, da die Java-Basisbibliotheken weniger bieten. Während .NET-Leute viel mehr von ihrem eigenen Code schreiben. Die Java-Community verfügt über ein größeres Ökosystem an Mustern und Praktiken, während .NET erneut eigenen Code schrieb oder auf Microsoft wartete. Dies ändert sich, zeigt aber erneut, warum .NET bei der Anforderung von Repos hinter Java steht.

Mark Channing
quelle
1
Hast du Paket ausprobiert?
Janus Troelsen
Mit .net Core haben wir heute Jetbrains Rider IDE. Ich werde mehr erwarten.
John
6

Wir verwenden NAnt, weil es keine echte Alternative gibt, die so ausgereift ist. Wir haben an mehreren Projekten gleichzeitig gearbeitet und uns darum gekümmert, mehrere Versionen von Bibliotheken zu haben und wie man damit umgeht. Das Maven-Angebot ist wirklich vielversprechend, aber nicht ausgereift genug, um auf der .NET-Plattform nützlich zu sein.

Ich denke, die Notwendigkeit ist weniger offensichtlich, da die meisten .NET-Projekte Visual Studio verwenden, das automatisch eine Verzeichnisstruktur, Abhängigkeiten usw. vorschlägt / erzwingt. Dies ist eine irreführende "Lösung", da abhängig von einer IDE für diese Art von Konventionen die Flexibilität des Entwicklungsteams eingeschränkt wird und Sie an eine bestimmte Lösung und einen bestimmten Anbieter gebunden sind. Dies ist in der Java-Welt offensichtlich nicht der Fall, daher ist eindeutig ein Maven-ähnliches Tool erforderlich.

Kamiel Wanrooij
quelle
Auf der anderen Seite haben wir von NAnt zu MSBuild migriert, da die manuelle Verwaltung des NAnt-Skripts ein großer Schmerz ist. VS erledigt das für Sie. Ich habe eine Master-MSBuild-Projektdatei, die von Hand im XML-Editor geschrieben wurde und Unit-Tests usw. startet und eine andere msbuild-Datei (von VS generiert) nur zum Erstellen der Quelle aufruft.
Ivan G.
Wenn man sich die Grafik des Github-Mitwirkenden ansieht, sieht es so aus, als ob NAnt stagniert hat. Würden Sie es trotzdem empfehlen?
Janus Troelsen
1
@JanusTroelsen Ich habe seit einigen Jahren nicht mehr in .NET gearbeitet. Ich habe herumgefragt und die am meisten gehörte Alternative sind NuGet-Pakete mit Paket oder einfach PowerShell.
Kamiel Wanrooij
2

Ich mag keine XML-basierten Build-Tools.

Wir haben Ruby Rake angepasst, um unsere .net-Produkte zu bauen. Albacore ist eine wirklich schöne Suite von Rake-Aufgaben zum Erstellen von .net-Projekten.

Mit Rake ist es wirklich einfach, selbst komplexe Build-Skripte zu erstellen, und Sie haben es mit Code statt mit Tonnen von spitzen Klammern zu tun.

Zebi
quelle
Benutzt du das noch? Ich sehe, dass Albacore noch lebt, mit Version 2.6.0, die gerade veröffentlicht wurde.
Janus Troelsen
2

Ich weiß, dass dies ein alter Beitrag ist, aber als ich darauf stieß, wollte ich eine andere großartige Alternative teilen.

Build Automation with PowerShell and Psake  

Viele Leute nutzen Psake (ausgesprochen Sockey) nicht aus. Das wirklich Coole ist, dass es msbuild verwendet.

Dies ist zwar keine Antwort auf die Maven-Frage (Maven entstand aus der Notwendigkeit von Java-Builds, die auf den langwierigen ausführlichen ANT-Skripten basieren).

Die meisten Leute verwenden kein CI (Continuous Integration) wie Jenkins, Hudson, Cruise Control, TeamCity, TFS und auch kein Powershell.

Dieses PSake for Powershell, das msbuild nutzt, sorgt dafür, dass die Dinge aufgabenorientiert und sehr gut organisiert sind. Hier ist ein Linkbeispiel http://www.shilony.net/2013/06/15/build-automation-with-powershell-and-psake/

Tom Stickel
quelle
1
Ich mag Psake wirklich, um Sachen zu bauen. Zum Verwalten von Abhängigkeiten möchte ich wirklich die Möglichkeit haben, packages.config-Dateien aus der Zeile nuget.command zu erstellen. Ungefähr so ​​wird es zum Beispiel in scriptcs gemacht.
8DH
Ja, als ich auf psake stieß, fing ich an, den Leuten davon zu erzählen.
Tom Stickel
Würden Sie Psake trotzdem empfehlen?
Janus Troelsen
@ JanusTroelsen Ich bin nicht sicher. Wahrscheinlich nicht, da ich in den letzten 3 Jahren noch niemanden darüber reden gehört habe.
Tom Stickel
"Maven entstand aus dem Bedürfnis nach Java-Builds basierend auf den langwierigen ausführlichen ANT-Skripten" ???
Seliger Geek
2

Wir verwenden UppercuT. UppercuT verwendet NAnt zum Erstellen und es ist das wahnsinnig einfach zu verwendende Build Framework.

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

https://github.com/chucknorris/uppercut/

Einige gute Erklärungen hier: UppercuT

Mehr Informationen


UppercuT ist ein herkömmlicher automatisierter Build, dh Sie richten eine Konfigurationsdatei ein und erhalten dann eine Reihe von Funktionen kostenlos. Die wohl leistungsstärkste Funktion ist die Möglichkeit, Umgebungseinstellungen an EINEM Ort anzugeben und überall anzuwenden, einschließlich der Dokumentation beim Erstellen der Quelle.

Dokumentation verfügbar: https://github.com/chucknorris/uppercut/wiki

Eigenschaften :

  • Einfache Einrichtung
  • Einfache Upgrades
  • Benutzerdefinierte Erweiterungspunkte (vor, nach und ersetzen) für jeden Schritt des Erstellungsprozesses http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
  • Enthält Dokumentation zur Integration mit Team City, CruiseControl.NET und Jenkins (ehemals Hudson) https://github.com/chucknorris/uppercut/tree/master/docs
  • Funktioniert unter Linux mit Mono
  • Versionierung von DLLs basierend auf Build-Nummer und Revisionen der Quellcodeverwaltung (SVN, TFS, Git, HG)
  • Kompilieren Sie Aktivitäten - F5 oder Strg + Umschalt + B.
  • Starke Benennung so einfach wie wahr / falsch
  • Code-Test und -Analyse
    • Testen
      • NUnit
      • MbUnit v2
      • Gallio
      • xEinheit
    • NCover
    • NDepend
    • Nitriq
    • Mono Migration Analyzer
  • Verschleierung
  • ILMerge
  • Erstellen und Erstellen von Umgebungen (ConfigBuilder, DocBuilder, SQLBuilder, DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
  • Paketausgabe zur Vorbereitung der Bereitstellung
  • Reißverschluss der Ausgabe
Inbrunstcodierer
quelle
Was macht es so einfach? Hat es irgendwelche wichtigen Verkaufsargumente gegenüber den anderen genannten, um die Verwendung dieses Produkts überzeugender zu gestalten?
Don Vince
Derick Bailey hat eine Zusammenfassung gemacht - lostechies.com/derickbailey/2010/05/10/…
ferventcoder
Was es einfach macht, ist, dass es sich um einen konventionellen Build handelt. Sie legen die Konfiguration fest und führen dann einfach build.bat aus. Wenn dem Uppercut neue Funktionen hinzugefügt werden, können Sie innerhalb von Sekunden ein Upgrade durchführen.
Ferventcoder
1
Hudson gibt es immer noch, Oracle "besitzt" es, aber die Entwickler mochten die Art und Weise, wie Oracle die Dinge ausführte, nicht und so schufen sie einen anderen Butlernamen namens Jenkins. Im Wesentlichen wurde Jenkins gut aufgenommen und seine Akzeptanzrate ist ziemlich beeindruckend.
Tom Stickel
Ich habe diesen Beitrag bearbeitet, um festzustellen, dass UppercuT aufgegeben wurde
Janus Troelsen