Innovations-Nummer +49 (0)7304 / 803 0

Blog-n-Roll:
Wissen,
das rockt!

ALM

2016.01.31

Päckchen packen mit NuGet, TFS 2015 und Build vNext. Teil 1: Pakete verwenden
By admin / 31 January / ALM, Entwickler / 0 comm.

Funktionalität automatisiert für andere Anwendungen bereitstellen Anmerkung: Dies ist die für Visual Studio / TFS 2015 und Build vNext überarbeitete Version unseres Artikels auf entwickler.de. Es hat sich Einiges getan: Das neue Buildsystem vereinfacht das zentrale Erstellen und Bereitstellen von NuGet-Paketen erheblich, und die NuGet-Integration in Visual Studio Team Services bietet einen einfachen weg, eigene […]

Funktionalität automatisiert für andere Anwendungen bereitstellen Anmerkung: Dies ist die für Visual Studio / TFS 2015 und Build vNext überarbeitete Version unseres Artikels auf entwickler.de. Es hat sich Einiges getan: Das neue Buildsystem vereinfacht das zentrale Erstellen und Bereitstellen von NuGet-Paketen erheblich, und die NuGet-Integration in Visual Studio Team Services bietet einen einfachen weg, eigene Paket-Feeds in der Cloud zu hosten. Viel Spaß! Der Open Source-Paketmanager NuGet hat sich in der .NET-Welt zur Standardmethode einwickelt, um Funktionalität zwischen mehreren Projekten zu teilen oder öffentlich bereitzustellen – fast jeder Programmierer hat schon ein NuGet-Paket in sein Projekt eingebunden. Doch NuGet kann mehr: Es bietet die Möglichkeit, wichtige Teile des Entwicklungsprozesses innerhalb der eigenen Organisation weiter zu verbessern und zu automatisieren.

Blogserie


  Der Paketmanager NuGet ermöglicht es, Funktionalität in handliche, versionierte Pakete (NuGet-Packages) zu packen und diese dann einfach für mögliche Konsumenten bereitzustellen. Das Tool war zunächst als Visual Studio-Erweiterung und Konsolenprogramm verfügbar, ab Visual Studio 2012 ist NuGet in die Entwicklungsumgebung integriert. Über öffentlich verfügbare Paketserver wie NuGet.org ist es sehr einfach, solche Packages zu veröffentlichen. Mittlerweile gibt es praktisch keine populäre Bibliothek mehr, die nicht über NuGet einfach in das eigene Projekt eingebunden werden kann – auch Microsoft selbst nutzt NuGet extensiv für die Bereitstellung von wichtigen Komponenten. Viele Visual Studio-Projektvorlagen enthalten Referenzen auf NuGet Packages, und selbst Teile des .NET Frameworks selbst werden mittlerweile auf diesem Weg ausgeliefert. Im Januar 2016 standen allein auf NuGet.org über 48.000 Pakete zum Download bereit. image In diesem Artikel wollen wir zwar zunächst einen Blick darauf werfen, wie man Pakete „konsumiert“ – aber bekanntlich ist Selbermachen viel schöner und nachhaltiger als Konsum. Deshalb zeigen wir auch, wie man „Päckchen packt“ – und zwar voll automatisiert und integriert in den Buildprozess. Zu guter Letzt geht es darum, wie NuGet den Softwareprozess in der eigenen Organisation verbessern kann. Also – Packen wir’s ein an!

Fertige Pakete zum eigenen Projekt hinzufügen

Bereits verfügbare NuGet-Pakete zu nutzen ist sehr einfach: Packages werden in Visual Studio über den Befehl Manage Nuget Packages… in die Projekte eingebunden. Dabei können einzubindenden Packages für eine einzelnes Projekt oder für die gesamte Solution verwaltet werden. Sollen Pakete in mehrere Projekte eingebunden werden empfiehlt sich der Aufruf von Manage NuGet Packages for Solutions… auf dem Solution-Eintrag im Solution Explorer: Es öffnet sich ein Dialog, in dem man auswählen kann, auf welche Projekte innerhalb der Solution die betreffende Referenz gesetzt werden soll. Dieser Befehl steht in Visual Studio im Menü Tools/Package Manager zur Verfügung. image Für einzelne Projekte kann der Aufruf über das Kontextmenü des Projekts oder der Projektreferenzen erfolgen – der angezeigte Dialog ist fast identisch, aber Änderungen betreffen hier nur das gewählte Projekt. Jetzt lassen sich einzelne Pakete suchen und installieren. Gerade die Suchfunktion ist dabei sehr hilfreich, denn wie erwähnt gibt es mittlerweile eine fast unüberschaubare Anzahl von verfügbaren Paketen. Das Paketmanagement untergliedert sich in unterschiedliche Bereiche mit jeweils eigenem Reiter:
  • Browse Hier werden alle Pakete angezeigt, die auf dem  im Dropdown-Feld Package Source gewählten Server verfügbar sind. Über den kleinen Zahnrad-Button rechts oben lassen sich weitere Paketserver wie beispielsweise MyGet.org oder auch lokale Server zur Auswahl hinzufügen. Wir werden später noch sehen, wie man eigene Package Sources erstellt.
  • Installed Hier werden alle Pakete angezeigt, die bereits im aktuellen Projekt bzw. in der Solution installiert sind.
  • Update Hier werden alle Pakete angezeigt, die bereits installiert sind und für die Updates bereitstehen.
  • Consolidate (nur für Solutions) Diese in Visual Studio 2015 neue Option ermöglicht es, auf einfache Weise alle Projekte in einer Solution auf die gleiche Version eines Pakets upzudaten.
  • Im rechten Bereich des Fensters können Pakete für alle oder einzelne Projekte installiert und deinstalliert werden, und es werden wichtige Informationen zu den Paketen angezeigt.Im vorliegenden Beispiel geht es um eine kleine “Hello World”-Konsolenapplikation, in die das Logging-Framework log4net eingebunden werden soll. Zunächst muss der Server gewählt werden, von dem das Pakt heruntergeladen werden soll (1); die geschieht über den Reiter Package Source rechts oben. Bei öffentlichen Paketen ist dies in der Regel der offizielle Paketserver unter NuGet.org. Dann kann die Bibliothek über das Suchfeld (2) lokalisiert werden und es werden die wichtigsten Infos über die gewählte Bibliothek angezeigt. Danach kann über Checkboxen bestimmt werden, für welche Projekte in der aktuellen Solution die Referenz gesetzt werden soll (3). Über den Install-Button wird die Bibliothek schließlich heruntergeladen und dem Projekt hinzugefügt (4).image Vorher präsentiert NuGet noch die Änderungen, die an der Solution vorgenommen werden sollen und fragt ganz höflich um Erlaubnis. Hat die eingebundene Bibliothek weitere Abhängigkeiten werden diese hier ebenfalls aufgelistet und automatisch mitinstalliert. image Schließlich lässt sich der Downloadprozess im Output-Fenster von Visual Studio mitverfolgen. image Jetzt kann die Bibliothek im Programmcode verwendet werden. image

    NuGet-Paketreferenzen

    Was passiert nun genau beim Einbinden einer NuGet-Paketreferenz? Beim Installieren eines Paketes legt NuGet automatisch innerhalb des entsprechenden Projektes eine Datei mit dem Namen packages.config an. In dieser Konfigurationsdatei merkt sich NuGet, welche Pakete in welcher Version im entsprechenden Projekt installiert sind. image image Die Pakete werden dann vom entsprechenden Server heruntergeladen und in einem Ordner namens packages abgelegt, der auf der Ebene des Solution-Files angelegt wird. Somit sind die Pakete auch nutzbar, wenn keine Verbindung zum Server besteht. Nun wird eine Referenz auf die entsprechende Datei unterhalb des packages-Ordners im Projekt eingetragen. image image Pakete können zusätzlich auch noch weitere Dateien, zum Beispiel Hilfe- oder Beispieldateien in das Projekt einbinden. So kann die Verwendung eines Paketes für den Nutzer vereinfacht werden. Zudem besteht die Möglichkeit, Konfigurationsdateien zu manipulieren und dort zusätzliche Einträge einzufügen, die bei der Deinstallation des Paketes auch wieder entfernt werden.

    Versionierung von Paketen

    Ein wichtige Funktion eines jeden Paketmanagers ist die Möglichkeit, Abhängigkeiten zu anderen Paketen definieren zu können. Beim Installieren eines Packages werden diese Abhängigkeiten ausgewertet und die entsprechenden Pakete automatisch mitinstalliert. Eine Voraussetzung dafür, dass dieser automatische und komfortable Prozess funktioniert ist es, dass der NuGet einen Versionierungs- und Update-Mechanismus mitbringt. Jedes Paket hat eine eindeutige Versionsnummer. Die Referenz im Projekt wird von NuGet immer auf die in der packages.config angegebene Version gesetzt. Durch die Bereitstellung einer neuen Version eines Paketes verändert sich das Verhalten zunächst nicht, da das Projekt immer noch die alte Version nutzt. Im Package Manager werden alle Pakete angezeigt, für die es eine neuere Version gibt. Diese können von dort entsprechend aktualisiert werden. Die neue Version des Paketes wird dann in den packages-Ordner heruntergeladen und die Referenz auf die neue Version abgeändert. Mit Visual Studio 2015 kann erstmals für jedes Paket direkt im Paketmanager bestimmt werden, in welcher Version es zur Solution oder zum Projekt hinzugefügt werden soll. Das war bisher nur über den Umweg der Package Manager Console möglich, die weiterhin im Menü Tools/Package Manager bereitsteht. Diese spezielle PowerShell-Kommandozeile ermöglicht mittels diverser Commandlets fortgeschrittene NuGet-Operationen. Eine Dokumentation dazu findet sich auf der offiziellen NuGet-Website. image NuGet und Versionsverwaltung Beim der Verwaltung von Solutions mit NuGet-Referenzen über die Versionsverwaltung zeigt NuGet auch in der aktuellen Version 2015 von Visual Studio ein nachvollziehbares aber trotzdem etwas unglückliches Verhalten: Standardmäßig wird der packages-Ordner in der Versionsverwaltung mit eingecheckt: image Dies hat zwar den Vorteil, dass die entsprechenden Pakete auch nach Auschecken der Solution durch einen anderen Benutzer sofort verfügbar sind – andererseits können die Pakete jederzeit vom jeweiligen Paketserver geladen werden. Das Einchecken in die Versionsverwaltung ist somit unnötig. Leider gibt es für den Ausschluss der Pakete aus der Versionsverwaltung keinen einfachen Befehl in den Visual Studio-Einstellungen. Stattdessen ist ein Eintrag (disableSourceControlIntegration) in der NuGet-Konfigurationsdatei nötig. image Diese Datei mit dem Namen nuget.config findet sich im Verzeichnis .nuget auf der Ebene der Solution – falls die Datei nicht existiert, kann sie auch manuell erstellt werden. Aber Achtung:  Beim Anlegen des Ordners .nuget nicht verzweifeln! Der Windows Explorer kann keine Verzeichnisse erstellen, die mit einem Punkt beginnen. Hier hilft nur der gute alte DOS-Befehl mkdir weiter. Wichtig auch: Änderungen an der Konfigurationsdatei werden erst nach Neustart von Visual Studio wirksam. image Danach wird der packages-Ordner automatisch im aktuellen Workspace unter Excluded Changes gelistet und nicht mit eingecheckt. image Ein Klick auf die von Visual Studio erkannten, aber vom Check In ausgeschlossenen Dateien [Detected: X add(s)] bestätigt, dass der Mechanismus wie gewünscht funktioniert. image Package Restore – Fehlende Pakete automatisch nachladen Nachdem das Einchecken des packages-Ordners unterbunden wurde, müssen die fehlenden Pakete dem Projekt vor einem Build wieder hinzugefügt werden, wenn die Solution an anderem Ort wieder frisch ausgecheckt wird. Dies erledigt NuGet automatisch per Package Restore. NuGet lädt dabei vor der eigentlichen Kompilierung die benötigten Pakete automatisch herunter, sobald in Visual Studio ein Build gestartet wird. Auch Team Builds auf einem dedizierten Buildserver werden unterstützt – dazu später mehr. Standardmäßig ist die Package Restore-Funktion in Visual Studio aktiviert, kann jedoch in den NuGet-Einstellungen auch abgeschaltet werden. Ab der NuGet-Version 2.7 ist Package Restore in Visual Studio integriert.
    NuGet_04
    Bei unserem kleinen Beispielprojekt lässt sich Package Restore ganz einfach testen: Einfach den packages-Ordner beherzt löschen, und beim nächsten Build repariert Visual Studio selbstständig und vollautomatisch das referenzierte Paket. image

    Fazit und Ausblick

    Soweit zum ersten Teil unserer kleinen NuGet-Serie. Im zweiten Teil werden wir uns damit beschäftigen, wie man eigene NuGet-Packages erstellt und für mögliche Konsumenten veröffentlicht. Vielen Dank für’s Lesen!
Nach oben