.NET-Abhängigkeitsmanagementsysteme

Ich habe einige .NET-Projekte, die langsam groß genug werden, um sich mit Dependency Management-Lösungen zu befassen, sodass wir keine Binärdateien von einem Projekt in ein anderes kopieren müssen. Folgendes habe ich bisher gefunden:

• NPanday basiert auf einem Hafen von Maven. Ich kann nicht sagen, wie kürzlich daran gearbeitet wurde, aber die letzte Veröffentlichung war im Mai 2011.
• NuGet scheint sich in der aktiven Entwicklung zu befinden und wird offenbar direkt von Microsoft unterstützt. Einige Leute haben sich darüber beschwert, dass es "nur die Abhängigkeitsauflösung behandelt", aber ich weiß nicht, was es sonst noch ansprechen soll oder ob es seitdem mehr Funktionen hinzugefügt hat. Es scheint, dass kürzlich die Möglichkeit hinzugefügt wurde, Binärdateien als Teil des Erstellungsprozesses zu importieren, sodass wir sie nicht in unsere Repositorys übertragen müssen.
• Refix scheint sich noch in der Beta zu befinden, nachdem es seit September 2011 keine Aufmerksamkeit mehr erhalten hat.

Würde jemand mit jüngsten Erfahrungen mit einem dieser Tools für das Abhängigkeitsmanagement (oder mit anderen, die gut funktionieren) Ihre Erfahrungen teilen? Ist NuGet ausgereift genug, um es für das Abhängigkeitsmanagement zu verwenden? Wenn nicht, was fehlt es?

NuGet wäre wahrscheinlich meine Antwort. Nachdem ich den Vorläufer (Nu) bearbeitet habe, der gerade auf RubyGems saß, kann ich sagen, dass es hilfreich ist, Ressourcen für etwas zu haben. Nach dem Job hatte ich eine gepatchte Version der ausführbaren Datei, da wir neben den entfernten ein lokales Repository hatten. Ich bin mir nicht sicher, ob sie dieses Problem noch behoben haben oder nicht, aber da sie Patches akzeptieren, sollte es leicht zu korrigieren sein. Bei allen Open Source-Projekten in der .NET-Arena, an denen ich arbeite, erledigen wir jetzt alles über NuGet. Es ist viel einfacher, obwohl das Veröffentlichen der Kette etwas länger dauert.

OpenWrap ist eine Option, aber alles muss gebaut werden. Welches ist ein bisschen ein Schmerz im Hintern. Wenn Sie das Projektgebäude nicht richtig gestalten können, dauert es eine Weile, bis es fertig ist. Openwrap hat lange versucht, dieses Problem zu lösen, und es ist immer noch sehr umständlich. Die binäre Verteilung ist (manchmal) viel einfacher ...

Die anderen beiden kenne ich nicht. Ich kann sie also nicht tonnenweise kommentieren.

Ich habe gerade eine neueste Version von NuGet heruntergeladen, um zu sehen, was sich seit dem letzten Mal geändert hat. Bitte korrigieren Sie mich, wenn ich falsch liege (ich denke wirklich darüber nach, meine Sachen auf Nuget zu migrieren):

NuGet-Pakete geben immer noch keine "Plattform" als Paketabhängigkeit an. Ich habe gerade "Ninject" installiert und es hat auf die .NET 4.0-Version in einem Unterordner "packages" verwiesen. Ich nehme an, es war eine gute Vermutung, da mein Projekt in 4.0 ist, aber das ist ziemlich gefährlich anzunehmen. Ich verstehe auch nicht, welche Plattform durch die Abhängigkeit der Pakete ausgewählt wird.

Die Funktion "Paketwiederherstellung" transformiert meine Lösung und fügt einen benutzerdefinierten Vorbereitungsschritt hinzu. Ich mag es nicht, wenn meine Lösungsdateien geändert werden, aber das ist kein Problem. Ich verstehe nicht, wie oft nach neuen Versionen gesucht wird (ich möchte eine Häufigkeit festlegen, mit der private Repositorys häufig verwendet werden).

Ich kann mich hier völlig irren, aber es sieht so aus, als würde Nuget die Projektabhängigkeit nicht automatisch aktualisieren, wenn eine Paketversion aktualisiert wird. Durch die Paketwiederherstellung wird ein neuer Unterordner für eine neue Paketversion erstellt. Ich muss diesen Ordner jedoch manuell aus Visual Studio auswählen und die Referenz vorher löschen.

Einige Pakete (wie jQuery) führen beim Start ein eingebettetes PowerShell-Skript aus. Ich mag keine benutzerdefinierte Ausführung und PS-Abhängigkeit, die unter Windows nicht immer vorhanden ist und in Mono-Builds ohne Windows völlig fehlt. Übrigens, wie ich bereits erwähnt habe, ist selbst diese Abhängigkeit für einige C ++ - Builds möglicherweise nicht realistisch (ansonsten wird mir die Funktion zur Paketwiederherstellung fehlen?).

Der letzte ist vielleicht nicht so wichtig, aber es dauert eine angemessene Zeit, um Abhängigkeiten wiederherzustellen, wenn ich ziemlich viele davon habe.

NuGet ist derzeit noch die beste Option.

Das Hauptproblem bei NuGet als Abhängigkeitsmanager besteht darin, dass es sich um einen Abhängigkeitsmanager mit "Entwicklungszeit" und nicht um einen Abhängigkeitsmanager mit "Erstellungszeit" handelt.

Ein Entwickler würde ein NuGet-Paket über Visual Studio wiederherstellen ... und dies könnte während der Wiederherstellung ein PowerShell-Skript ausführen, das Dateien im Projekt ändert.

Dies ist anders als bei anderen Abhängigkeitsverwaltungssystemen, die ich gesehen habe, da das Hinzufügen und Auflösen einer Abhängigkeit das System ändern kann, das auf die Abhängigkeit verweist.

Es gibt keinen integrierten Mechanismus zum Sicherstellen oder Überprüfen der Idempotenz im PowerShell-Skript. Daher ist es möglicherweise nicht deterministisch, es mehrmals auf demselben Dateisatz auszuführen.

Es scheint, dass viele NuGet verwenden, um Pakete während der Entwicklungszeit durch Visual Studio zu ziehen, aber mir ist keine solide Empfehlung bekannt, wie dies auf einem Build-Server funktionieren soll.