Such das File! Brav!

Kommandozeilentools, die nicht im aktuellen Suchpfad von Windows liegen. PowerPoint-Präsentationen, die ich versehentlich im falschen Verzeichnis gespeichert habe. Mehrmals täglich ärgere ich mich darüber, dass die Windows-Dateisuche entweder quälend langsam abläuft oder aber nicht aktuell ist. Denn oft ist der Index-Service gar nicht aktiviert oder hat die gesuchte Datei noch nicht indiziert.

Abhilfe schafft bei mir seit kurzen das kleine Tool Search Everything, eine absurd schnelle Desktopsuche mit minimalem Footprint – der Installer “wiegt” 1,4 MB und sogar eine portable Version gibt es.

image

Search Everything kann nur Dateinamen suchen – das reicht mir aber in 95% der Fälle. Das Tool arbeitet direkt mit dem NTFS-Filesystem und macht die Suche so schnell, dass Verzögerungen praktisch nicht wahrnehmbar sind. Übrigens: Auch Nicht-NTFS-Pfade können durchsucht werden, dieses Feature muss aber explizit aktiviert werden und die Suche geht für solche Verzeichnisse auch etwas langsamer vonstatten.

Prädikat: Unverzichtbar!

Päckchen packen mit NuGet, TFS 2017 und Build vNext. Teil 1: Pakete verwenden

Funktionalität automatisiert für andere Anwendungen bereitstellen

Image copyright by James Nash - https://www.flickr.com/photos/james_nash/4758670232/in/photolist-8fvqSu-d93UjS-2yHKaK-dgGf8V-breB8a-hwmvWR-VkSewo-9NFDfs-mZKyEz-7mT685-VjZV87-oPyU-nL3T1h-ebi53-iTdYY-nfS7Qt-2yHJ6H-7RTVU-9aCDgC-2yN7U5-trGLK-iTdBL-4FLSva-5ww7gW-8sY99L-5QL8mG-6kBgMP-2yN7YQ-3K1aqw-9mHZwr-7DabS3-nfScgV-8qeZNM-AvBvm-i9hZR-2yN98L-4vNTAj-99S1CJ-f6HraB-5zFUGH-2yN7tw-hXNh6m-6wY2Rw-EbXke-8mcnD-nvAY9U-cHvyA5-FKNmL-iTea4-h5SZEF

Anmerkung: Dies ist die für Visual Studio / TFS 2017 und Build vNext überarbeitete Version eines Artikels, den ich ursprünglich mit Thomas Schissler auf entwickler.de veröffentlicht habe. 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

Teil 1: Pakete verwenden (dieser Artikel)

Teil 2: Pakete erstellen

Teil 3: Pakete verteilen

Teil 4: Pakete debuggen


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 – im Juni 2017 war die Zahl auf 82.000 Pakete gewachsen.

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

SNAGHTML568256e

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 solche eigenen “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 ab Visual Studio 2015 neue Option ermöglicht es, auf einfache Weise alle Projekte in einer Solution auf die gleiche Version eines Pakets upzudaten.

image

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 Paket 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 in der gewünschten Version heruntergeladen und dem Projekt hinzugefügt (4).

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 verfolgen.

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

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

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.

Ab 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

Sollen die von NuGet in die Solution eingebundenen Pakete in die Versionsverwaltung eingecheckt werden? Dies hätte zwar den Vorteil, dass die entsprechenden Pakete auch nach Auschecken der Solution durch einen anderen Benutzer sofort verfügbar wären – andererseits können die Pakete jederzeit vom jeweiligen Paketserver geladen werden. Das Einchecken in die Versionsverwaltung ist somit unnötig.

Wird git als zugrundeliegende Versionsverwaltung eingesetzt, sorgt ein entsprechender Eintrag im .gitignore-File dafür, das Visual Studio sich wie gewünscht verhält:

image

Auch mit Team Foundation Version Control verhält sich wie Visual Studio 2017 mittlerweile wie erwartet – bei älteren Versionen muss man noch manuell nachhelfen – wie, das verrät Donovan Brown in seinem Blog.

Die Zukunft: Adieu, package.config

Mit NuGet 4.0 und Visual Studio 2017 hat Microsoft eine weitere Änderung umgesetzt, welche die Arbeit mit NuGet einfacher und übersichtlicher machen soll: Anstatt in der separaten packages.config-Datei können die Informationen über Paketreferenzen jetzt auch optional im in Projektfile gespeichert werden. Dazu sind einige Einstellungen nötig: In Dialog Options/NuGet Package Manager kann das Verhalten unter Default package management format umgestellt werden:

  • packages.config ist die Standardvorgabe für klassische .NET Anwendungen – Visual Studio nutz hier nutzt wie gehabt packages.config als Speicherort für NuGet-Referenzinformationen.
  • Die Option PackageReference verzichtet auf dieses File und legt stattdessen entsprechende Einträge im Projektfile an. Für .NET Core Projekte ist dieses Verhalten bereits Standard. Achtung: Um diese Variante nutzen zu können ist wie bereits erwähnt zwingend Visual Studio 2017 und/oder je nach Anwendungsfall die NuGet.exe Kommandozeilen-Anwendung ab Version 4.x nötig. Dazu mehr in den späteren Folgen der Artikelserie.

trypackageref

Mit der Option Allow format selection on first package install ist es zudem möglich, beim ersten Hinzufügen einer Package individuell eine der beiden Varianten zu wählen:

image

Um bei der “configlosen” Variante die NuGet-Referenzinformationen im Projektfile betrachten zu können, muss das Projekt zunächst entladen werden (Rechtsklick auf das Projekt – Kontextmenü Unload Project). Jetzt kann das Projektfile geöffnet werden – es sollte die entsprechenden PackageReference XML-Nodes enthalten.

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.

image

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.

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!