Im Laufe der Zeit fallen zahlreiche kleinere Hilfs-Bibliotheken, Abstraktionen und dergleichen an. Wer es gut meint, erstellt ein eigenes Repository im Source Control und eventuell gibt es noch einen Hinweis an die Kollegen. Ganz selten ergeht dieser auch an andere Abteilungen. Zur Verwendung gelangen derartige “gute Gedanken” kaum, zumal das Einbinden schon einige Schritte notwendig macht (Clone, Build etc.). Schade eigentlich. Dabei würden 15 Minuten Aufwand dieses Problem beheben.

Im Laufe der Zeit fallen zahlreiche kleinere Hilfs-Bibliotheken, Abstraktionen und dergleichen an. Wer es gut meint, erstellt ein eigenes Repository im Source Control und eventuell gibt es noch einen Hinweis an die Kollegen. Ganz selten ergeht dieser auch an andere Abteilungen. Zur Verwendung gelangen derartige “gute Gedanken” kaum, zumal das Einbinden schon einige Schritte notwendig macht (Clone, Build etc.). Schade eigentlich. Dabei würden 15 Minuten Aufwand dieses Problem beheben.

Problemstellung

Ich denke, dass es vielen nicht anders gehen wird. Ein kleiner Auszug aus existierenden “Helferleins”:

  • Wrapper für Logging
  • Einfacher Data Layer
  • Basis-Klassen + Helferleins für Integrationstests (REST API)
  • Erweiterungen für xUnit

Vieles würde sich noch finden lassen, alles darf ich ja nicht ausplaudern :) Das Problem bei der Sache ist aber vielfach, dass jemand eine gute Idee hat, diese umsetzt, ins aktuelle Projekt einbindet und das war es dann wieder.

Wer es verwenden möchte, würde es zwar in der Source Control als eigenständiges Repository finden, das Einbinden ins eigene Projekt gestaltet sich jedoch schwierig. Immerhin muss man es zuerst klonen, dann kompilieren usw. Laut Murphy ist es dann gar nicht so einfach wie man denkt.

Der Nachteil dabei ist, dass mehrmals derselbe Gedanke umgesetzt, verwendet und gepflegt wird. Eine Arbeit, die so überhaupt nicht notwendig wäre.

Eigener NuGet-Server

Um das Problem der doppelten Arbeit und des Nichtverwendens weil nicht komfortabel zu lösen, habe ich mich kurzerhand entschlossen, einen NuGet-Server aufzusetzen. Hierzu sind folgende Schritte notwendig:

  • Visual Studio öffnen (ich habe 2013 verwendet)
  • Leere Webanwendung erstlelen (New project -> ASP.NET Web Application -> Empty)
  • Kontextmenü auf dem Projekt öffnen -> Manage NuGet Packages
  • Package NuGet.Server installieren
  • Eventuell einige Einstellungen in der Web.config ändern (jedenfalls sollte der API-Key gesetzt werden)
  • Kompilieren
  • Deployment auf einen Server

Und schon kann es los gehen.

Hilfreiche NuGet Links

Folgende Seiten könnten weiter helfen (haben zumindest mir geholfen):

Fazit

Läuft der Server erst einmal, einfach die ersten Packages erstellen und einspielen. Anschließend den Kollegen kurz zeigen wie man darauf zugreifen kann und schon löst man einen kleinen Hype aus. Eine positive Entwicklung sollte vorprogrammiert sein ….

Update: Mittlerweile existiert unter github.com/fsprojects/paket ein Dependency Manager für .NET mit Unterstützung für NuGet und GitHub. Ein Blick auf dieses Projekt empiehlt sich sehr, hilft es doch, Abhängigkeiten sauber und konfliktfrei zu halten.

Über den Autor

Norbert Eder

Ich bin ein leidenschaftlicher Softwareentwickler und Fotograf. Mein Wissen und meine Gedanken teile ich nicht nur hier im Blog, sondern auch in Fachartikeln und Büchern.