NuGet

Verwalten von Projektbibliotheken mit NuGet

Phil Haack

 

So sehr sich Microsoft auch bemühen mag, es ist uns leider nicht möglich, jedem einzelnen Entwickler jede erdenkliche Bibliothek bereitzustellen. Microsoft verzeichnet weltweit zwar fast 90.000 Mitarbeiter, dem gegenüber stehen jedoch Millionen von Entwicklern. Für Microsoft ist es nicht sinnvoll zu versuchen, jede einzelne Marktnische zu füllen oder hinsichtlich der Größe anzupassen. Entwickler wissen sich daher häufig selbst zu helfen und haben Tausende nützlicher Bibliotheken geschrieben, die im ganzen Web verteilt werden.

Bei der großen Anzahl von Bibliotheken fragt sich nur: Wie können sie am besten freigegeben werden? Die Freigabe und Wiederverwendung von Code stellt immer noch eine große Herausforderung dar. Sie glauben mir nicht? Fragen Sie doch einmal in einem mittelständischen bis großen Unternehmen nach, über wie viele Protokollbibliotheken es verfügt. Nach einer Weile werden Sie feststellen, dass viele unternehmensinterne Protokollbibliotheken entwickelt werden, obwohl sich bereits sehr brauchbare Bibliotheken auf dem Markt befinden: Log4Net, NLog und Error Logging Modules and Handlers (ELMAH).

Wenn ein Entwickler ein neues Projekt startet, weiß er manchmal nicht, wo er anfangen soll. Wie kann er diese nützlichen Bibliotheken finden? Wie kann er eine Bibliothek in sein aktuelles Projekt integrieren und ihre Abhängigkeiten und Aktualisierungen verwalten?

ELMAH ist ein gutes Beispiel für eine nützliche Bibliothek, die Entwickler selbst geschrieben haben. ELMAH protokolliert alle Ausnahmefehler in einer Webanwendung zusammen mit allen Anforderungsinformationen, wie Headern, Servervariablen usw., wenn die Ausnahme ausgelöst wird. Angenommen, Sie haben eben zum ersten Mal von ELMAH gehört und möchten die Bibliothek für Ihr nächstes Projekt verwenden.

Sie können so vorgehen:

1. Suchen Sie ELMAH. Dank des einmaligen Namens werden nach einer Suche in Bing die Google-Codeseiten von ELMAH als erstes Ergebnis geliefert.
2. Laden Sie das richtige ZIP-Paket herunter. Auf der Downloadseite der Website stehen mehrere ZIP-Pakete zur Verfügung. Wählen Sie das richtige Paket aus. Verlassen Sie sich dabei nicht auf Ihr Bauchgefühl.
3. Heben Sie die Blockierung für das Paket auf. Nachdem Sie das Paket aus dem Web heruntergeladen haben, klicken Sie mit der rechten Maustaste auf die Datei. Klicken Sie in dem angezeigten Dialogfeld „Eigenschaften“ auf die Schaltfläche „Blockierung aufheben“, um das „Mark of the Web“ aus der Datei zu entfernen.
4. Überprüfen Sie den Hashcode anhand des Werts, der durch die Hostingumgebung zur Verfügung gestellt wurde. Auf der Google-Codewebsite wird ein QR-Code angezeigt, der für die ZIP-Datei steht. Wie viele Entwickler kennen Sie, die sich die Zeit nehmen, um die Datei mit dem QR-Code zu vergleichen?
5. Entzippen Sie den Paketinhalt an einem bestimmten Speicherort in der Projektmappe. Die meisten Entwickler vermeiden es, die Assemblys in dem BIN-Verzeichnis zu entpacken, weil das Verzeichnis nicht für die Eingabe, sondern für die Ausgabe des Builds gedacht ist und durch die Versionskontrolle nicht nachverfolgt wird. Stattdessen ist es wichtig, die Abhängigkeit einem Ordner hinzuzufügen, der der Versionskontrolle unterliegt, und von dem Speicherort aus auf die Assembly zu verweisen.
6. Fügen Sie dem Projekt einen Assemblyverweis hinzu. Die Assembly kann erst verwendet werden, wenn Sie im Visual Studio-Projekt einen Verweis darauf erstellt haben.
7. Aktualisieren Sie „web.config“ mit den gültigen Einstellungen. Möglicherweise müssen Sie hierfür bei Bing oder Google suchen, um die korrekten Einstellungen für Ihre Konfigurationsdatei zu ermitteln.

Was für eine Arbeit! Stellen Sie sich vor, dass Sie dies für 10 bis 15 Abhängigkeiten durchführen müssten. Wie viel Zeit würden Sie bei der Freigabe der nächsten Version Ihrer Anwendung für die Suche nach Aktualisierungen für die Abhängigkeiten Ihrer Anwendung aufwenden?

Das häufig kritisch beäugte Statement „nicht hier erfunden“ (Not Invented Here, NIH) ist vielleicht doch gar keine so schlechte Idee.

NuGet ist die Rettung

NuGet ist eine Visual Studio-Erweiterung, mit der das Hinzufügen, Aktualisieren und Entfernen von (als Paketen bereitgestellten) Bibliotheken in einem Visual Studio-Projekt zum Kinderspiel wird. Ein NuGet-Paket besteht aus einem Satz Dateien, die in einer einzigen Datei unter Verwendung des OPC-Formats (Open Packaging Conventions) mit der Erweiterung NUPKG verpackt werden.

OPC ist einfach ein modernes Akronym für eine ZIP-Datei mit ein paar Metadaten. Sie kennen sicherlich bereits OPC, da das Format in Word- und Excel-Dokumenten verwendet wird. Falls Sie jemals die Erweiterung einer DOCX-Datei zu ZIP geändert haben, ist Ihnen bekannt, dass Sie diese Datei öffnen und ihre Inhalte anzeigen können. Dasselbe gilt für NUPKG-Dateien.

Das NuGet-Produkt enthält auch einige Dienstprogramme zur einfachen Erstellung und Veröffentlichung von Paketen. Im Folgenden möchte ich mich zunächst auf das Ermitteln und Installieren von Paketen mit NuGet konzentrieren. Anschließend werde ich auf das Erstellen und Veröffentlichen von Paketen zurückkommen.

Installieren von NuGet

Wechseln Sie zum Installieren von NuGet zur Menüoption „Tools“ | „Erweiterungs-Manager“, und starten Sie den Erweiterungs-Manager in Visual Studio. Klicken Sie auf die Registerkarte „Onlinekatalog“, um die verfügbaren Visual Studio-Erweiterungen anzuzeigen (siehe Abbildung 1). Wie auf der Abbildung zu erkennen ist, wird NuGet auf dem ersten Bildschirm angezeigt. Das liegt daran, dass das Paket die beste Bewertung erhalten hat. Sollte sich dies in Zukunft ändern, können Sie NuGet über das Suchfeld oben rechts suchen. Klicken Sie auf „Herunterladen“, um NuGet zu installieren.

Abbildung 1: Erweiterungs-Manager in Visual Studio

Wenn Sie ASP.NET MVC 3 installiert haben, wurde NuGet bereits mitinstalliert. ASP.NET MVC 3 enthält NuGet, und Microsoft plant, NuGet in die nächste Version von Visual Studio aufzunehmen.

Installieren eines Pakets

Zunächst möchte ich auf das benutzerfreundliche Dialogfeld von NuGet zum Installieren von Paketen eingehen. Im Lieferumfang von NuGet ist eine Windows PowerShell-basierte Konsole für Hauptbenutzer enthalten, die ich später erläutern werde.

Klicken Sie zum Starten von NuGet mit der rechten Maustaste auf den Referenzknoten des Projekts, und wählen Sie die Option „NuGet-Pakete verwalten“ aus (diese Option hatte vor NuGet 1.4 eine andere Bezeichnung). Dadurch wird das Dialogfeld „NuGet-Pakete verwalten“ geöffnet (siehe Abbildung 2).

Abbildung 2: Dialogfeld „NuGet-Paket-Manager“

Stellen Sie sicher, dass die Registerkarte „Online“ ausgewählt ist, und geben Sie oben rechts einen Suchbegriff ein (suchen Sie beispielsweise nach „MiniProfiler“, einer nützlichen Bibliothek von den Entwicklern auf StackOverflow.com).

Sobald Sie ein Paket gefunden haben, klicken Sie auf die Schaltfläche „Installieren“, um das Paket zu installieren. NuGet lädt dann das Paket und seine Abhängigkeiten herunter und wendet den Angaben in den Paketen gemäß die erforderlichen Änderungen auf Ihr Projekt an.

In NuGet werden die folgenden Schritte zum Installieren eines Pakets ausgeführt:

1. Herunterladen der Paketdatei und aller Abhängigkeiten: Für einige Pakete ist das explizite Akzeptieren einer Lizenz erforderlich. In diesem Fall wird der Benutzer aufgefordert, die Lizenzbedingungen für das Paket anzunehmen. Bei den meisten Paketen wird jedoch implizit von einer Zustimmung ausgegangen, und der Benutzer wird nicht speziell dazu aufgefordert, die Lizenz zu akzeptieren. Falls das Paket bereits in der Projektmappe oder im Cache des lokalen Computers vorhanden ist, wird der Schritt zum Herunterladen des Pakets übersprungen.
2. Extrahieren der Paketinhalte: In NuGet werden die Inhalte in den Paketordner extrahiert. Falls erforderlich, wird der entsprechende Ordner erstellt. Der Paketordner befindet sich neben Ihrer Projektmappendatei (SLN-Datei). Wenn dasselbe Paket in mehreren Projekten innerhalb einer Projektmappe installiert wird, wird es nur einmal extrahiert und von den Projekten gemeinsam verwendet.
3. Verweisen auf Assemblys im Paket: Entsprechend der Konvention wird in NuGet der Projektverweis auf die entsprechende Assembly (oder die Assemblys) im Ordner lib des Pakets aktualisiert. Wenn beispielsweise ein Paket in einem Projekt mit dem Ziel Microsoft .NET Framework 4 installiert wird, werden die Verweise auf Assemblys im Ordner lib/net40 hinzugefügt.
4. Kopieren von Inhalten in das Projekt: In NuGet werden die Inhalte des Inhaltsordners des Pakets standardmäßig in das Projekt kopiert. Dies ist insbesondere bei Paketen mit JavaScript-Dateien oder Bildern nützlich.
5. Anwenden von Pakettransformationen: Wenn ein Paket Transformationsdateien wie „app.config.transform“ oder „web.config.transform“ zum Konfigurieren enthält, werden diese Transformationen vor dem Kopieren der Inhalte angewendet. Einige Paket enthalten möglicherweise Quellcode, der so umgewandelt werden kann, dass er den aktuellen Namespace des Projekts in der Quelldatei enthält. In NuGet werden auch diese Dateien umgewandelt.
6. Ausführen von zugehörigen Windows PowerShell-Skripts im Paket: Einige Pakete enthalten möglicherweise Windows PowerShell-Skripts, mit denen Visual Studio automatisiert wird. Dabei wird Design Time Environment (DTE) für Aufgaben eingesetzt, für die NuGet nicht geeignet ist.

Nachdem alle oben beschriebenen Schritte ausgeführt wurden, kann die Bibliothek verwendet werden. Viele Pakete stellen mithilfe des WebActivator-Pakets eigene Verbindungen her, um nach der Installation erforderliche Konfigurationen auf ein Minimum zu beschränken.

Durch die Deinstallation eines Pakets wird das Projekt in den Zustand zurückversetzt, in dem es sich vor der Installation des Pakets befand.

Aktualisieren von Paketen

Robert L. Glass bemerkt in seinem Buch „Facts and Fallacies of Software Engineering“ (Addison-Wesley Professional, 2002) Folgendes: „Die Verwaltung macht in der Regel 40 bis 80 Prozent (durchschnittlich 60 Prozent) der Softwarekosten aus. Aus diesem Grund ist sie wahrscheinlich die wichtigste Lebenszyklusphase.“

Aber das Installieren eines Pakets ist nur der Anfang. Im Laufe der Zeit, während der Verwaltung dieser Bibliotheken, wird es wichtig, die Anwendung immer mit den neuesten Fehlerbehebungen für die Bibliotheken aktuell zu halten. Dies zwingt Sie, die folgende Frage zu beantworten: „Für welche Abhängigkeiten in diesem Projekt sind neue Updates verfügbar?“

Wie bereits zuvor bemerkt, benötigen Sie zum Beantworten dieser Frage viel Zeit. Mit NuGet, können Sie jedoch einfach das Dialogfeld öffnen und auf die Registerkarte „Updates“ klicken, um eine Paketliste mit verfügbaren Updates anzuzeigen (siehe Abbildung 3). Klicken Sie auf die Schaltfläche „Update“, um das Paket auf die neueste Version zu aktualisieren.

Abbildung 3: Verfügbare Updates für das aktuelle Projekt

Durch den Aktualisierungsbefehl wird das alte Paket deinstalliert, und das neue Paket wird installiert. Dabei wird sichergestellt, dass alle Abhängigkeiten nach Bedarf aktualisiert werden.

In NuGet stehen in der Paket-Manager-Konsole Befehle für eine bessere Steuerung von Updates zur Verfügung, zum Beispiel zum Aktualisieren aller Pakete in der Projektmappe oder zum Ausführen eines „sicheren“ Updates.

NuGet für Hauptbenutzer

Ich bin zwar ein großer Fan von benutzerfreundlichen GUI-Dialogfeldern, kenne aber viele Entwickler, die solche „Maus ziehenden Menschen“ wie mich verachten. Sie verwenden lieber eine Befehlszeilenshell als Benutzeroberfläche, da sie mit ihr mehrere Befehlssätze gleichzeitig verfassen können.

NuGet wird diesem Anspruch gerecht und bietet ein Windows PowerShell-basiertes Konsolenfenster mit der Bezeichnung „Paket-Manager-Konsole“ sowie einen Satz an Windows PowerShell-Befehlen für die Interaktion mit NuGet. Windows PowerShell, eine .NET-basierte Skriptsprache und Befehlszeilenshell, eignet sich gut für das Verfassen von Befehlssätzen und Arbeiten mit Objekten.

Navigieren Sie zum Starten der Paket-Manager-Konsole zur Menüoption „Tools“ | „Bibliotheks-Paket-Manager“ | „Paket-Manager-Konsole“.

Auflisten und Installieren von Paketen

Verwenden Sie den Befehl „Get-Package“ zum Auflisten von und Suchen nach Paketen. Standardmäßig werden mithilfe des Befehls installierte Pakete des aktuellen Projekts aufgeführt. Sie können online durch Angabe des Kennzeichens „ListAvailable“ in Kombination mit dem Kennzeichen „Filter“ nach Paketen suchen. Mit dem folgenden Befehl können Sie nach allen Paketen suchen, die „MVC“ enthalten:

Get-Package -ListAvailable -Filter Mvc

Sobald Sie ein Paket zum Installieren gefunden haben, verwenden Sie den Befehl „Install-Package“. Gehen Sie zum Beispiel so vor, um ELMAH im aktuellen Projekt zu installieren:

Install-Package Elmah

Da Windows PowerShell eine dynamische Sprache ist, kann sie Befehlsergänzungen zur Unterstützung der korrekten Eingabe von Befehlsargumenten bieten. Befehlsergänzungen sind mit IntelliSense für C# vergleichbar, können jedoch zur Laufzeit gefüllt werden. Mit dem auf Kompilierzeitinformationen basierenden IntelliSense ist dies nicht möglich.

Wenn Sie beispielsweise „Install-Package Mvc{tab}“ eingeben, wird eine Liste möglicher Paketnamen aus der Paketquelle angezeigt (siehe Abbildung 4).

Abbildung 4 Mit TAB ergänzte Paketliste

Aktualisieren von Paketen

Die Paket-Manager-Konsole enthält auch einen Befehl, mit dem Sie die Updates besser als in dem Dialogfeld steuern können. So können Sie diesen Befehl beispielsweise ohne Argumente aufrufen, um jedes Paket in jedem Projekt der Projektmappe zu aktualisieren:

Update-Package

Mit diesem Befehl wird versucht, jedes Paket auf die neueste Version zu aktualisieren. Wenn Sie nun Version 1.0 eines Pakets besitzen und Version 1.1 und Version 2.0 in der Paketquelle verfügbar sind, aktualisiert dieser Befehl das Paket auf Version 2.0, weil dies die neueste Version ist.

Dies kann eine drastische Maßnahme sein, wenn ein Paket grundlegende Änderungen enthält. In vielen Fällen möchten Sie jedoch jedes Paket einfach nur auf die letzte Version mit behobenen Fehlern aktualisieren. Dies wird als „sicheres“ Update bezeichnet. Dabei wird davon ausgegangen, dass Pakete mit einer höheren Build- oder Revisionsnummer (aber mit denselben Haupt- und Nebennummern) abwärtskompatibel sind. Gehen Sie so vor, um das Kennzeichen „Safe“ hinzufügen und ein sicheres Update auszuführen:

Update-Package -Safe

Wenn Sie in diesem Fall Version 1.0.0 eines Pakets installiert haben und Version 1.0.1 sowie Version 1.1 in der Paketquelle verfügbar sind, wird das Paket sicher auf Version 1.0.1 und nicht auf 1.1 aktualisiert.

Der Befehl „Update-Package“ bietet auch mehr Präzision, wie das Aktualisieren eines Pakets auf eine bestimmte Version des Pakets und nicht auf die letzte Version.

Erweitern von Visual Studio mit neuen Befehlen

Auch wenn das Installieren von Paketen mit Windows PowerShell durchaus praktisch sein mag, ist dies nicht der Hauptgrund, Windows PowerShell zu wählen. Ein viel überzeugenderer Grund besteht in der Möglichkeit, der Pakete-Manager-Konsole mit Paketen neue Befehle hinzuzufügen. Diese Befehle können mit Visual Studio DTE interagieren, um verschiedene Aufgaben auszuführen.

Dazu gehören das Installieren des MvcScaffolding-Pakets und das Hinzufügen des Befehls „Scaffold Controller“ zur Konsole. Dieser Befehl generiert anhand eines Code First-Objekts aus Entity Framework (EF) einen Controller, Controller-Aktionen und Ansichten, die den grundlegenden Operationen für das EF-Objekt (CRUD: Create, Read, Update and Delete) entsprechen (Abbildung 5).

Abbildung 5: „MvcScaffolding“ – benutzerdefinierter Befehl „Scaffold“ in Aktion

NuGet in Ihrem Unternehmen

Da NuGet vor allem für seine Vorteile beim Freigeben von Bibliotheken in der öffentlichen Entwicklercommunity bekannt ist, werden die Vorteile für die Unternehmen leicht übersehen.

Schließlich ist es nichts Besonderes für Unternehmen, wenn Bibliotheken gegenüber denselben Herausforderungen immun werden, mit denen die Softwarecommunity insgesamt beim Freigeben von Code konfrontiert ist. Im Laufe der Jahre, während ein Unternehmen wächst, wird immer mehr dem Zufall überlassen. Unterschiedliche Gruppen innerhalb des Unternehmens verlassen sich auf ihre eigenen privaten Versionen „standardmäßiger“ Unternehmensbibliotheken. Einige Gruppen ignorieren diese Bibliotheken sogar vollständig und schreiben eigene, vollkommen neue Bibliotheken.

Das Problem besteht häufig nicht in den Bibliotheken selbst, sondern in den Problemen, die mit der Freigabe der Bibliotheken für andere Teams und der Benachrichtigung über Änderungen verbunden sind. Kommt Ihnen das bekannt vor?

Paketquellen

Bisher bin ich auf das Installieren von Paketen eingegangen, habe aber die wichtigste Frage noch nicht beantwortet: Wo werden diese Pakete gespeichert? Sie befinden sich im offiziellen NuGet-Paketkatalog unter „nuget.org“. Dieser Katalog enthält einen OData-Feed: packages.nuget.org/v1/FeedService.svc.

Der NuGet-Client kann mithilfe des OData-Formats Ad-hoc-Abfragen zum Durchsuchen der Paketquelle auf dem Client generieren, diese jedoch auf dem Server ausführen.

Navigieren Sie zum Hinzufügen weiterer Paketquellen zu NuGet zur Menüoption „Tools“ | „Bibliotheks-Paket-Manager“ | „Paket-Manager-Konsole“, und klicken Sie auf den Knoten für die Paketquellen (siehe Abbildung 6).

Abbildung 6: Paket-Manager-Einstellungen

Die Standardpaketquelle ist ein OData-Endpunkt im Web. Das Beispiel auf dem Screenshot zeigt jedoch auch einen lokalen Ordner als Paketquelle. NuGet behandelt Ordner (sowohl lokale Ordner als auch Ordner auf einer Netzwerkfreigabe) als Paketquelle und listet jedes Paket im Ordner im Bereich „Online“ auf. Dies erleichtert die Freigabe von Code für andere Benutzer ungemein, der Vorgang ist mit dem Verschieben in einen Ordner vergleichbar. Beim Testen von Paketen, die Sie selbst erstellen, ist dies auch nützlich.

Hosten eines eigenen NuGet-Servers

Neben dem Hosten von Paketen auf einer Netzwerkfreigabe können Sie auch eine Website als Paketquelle einrichten und sie zum Freigeben von Paketen für andere Benutzer in Ihrer Organisation verwenden.

Wie auch bei anderen Aufgaben erhalten Sie hier von einem Paket Unterstützung. Erstellen Sie als Erstes in Visual Studio eine leere ASP.NET-Webanwendung (mit Ausrichtung auf ASP.NET 4). Installieren Sie das Paket NuGet.Server in NuGet. Mit diesem Paket wird der leeren Webanwendung ein einfacher OData-Endpunkt hinzugefügt.

Fügen Sie als Nächstes dem Paketordner der Webanwendung Paketdateien hinzu, um sie zu veröffentlichen und die Website bereitzustellen. Weitere Informationen zur Einrichtung finden Sie auf der NuGet-Dokumentationswebsite „bit.ly/jirmLO“.

Für diejenigen, die eine vollständige Katalognutzung wie „nuget.org“ bereitstellen möchten, steht der NuGet-Katalogcode als Open-Source-Projekt über das Projekt „nugetgallery.codeplex.com“ zur Verfügung.

Über das Hosten eines NuGet-Servers oder einer Katalogimplementierung kann proprietärer Code einfach innerhalb eines Unternehmens freigegeben werden, ohne ihn der Öffentlichkeit verfügbar zu machen.

Erstellen eines Pakets

NuGet wäre ohne zu installierende Pakete wenig sinnvoll. Je mehr nützliche Pakete in NuGet zur Verfügung stehen, desto mehr Nutzen kann jeder Entwickler aus NuGet ziehen. Aus diesem Grund hat das NuGet-Team keine Mühen gescheut, das Erstellen von Paketen so einfach und unkompliziert wie möglich zu gestalten. Obwohl Pakete bereits mühelos erstellt werden können, arbeitet das NuGet-Team an weiteren Funktionen, die das Erstellen noch einfacher machen. Es hat bereits mehrere Tools zum Erstellen von NuGet-Paketen erstellt. Beim Paket-Explorer handelt es sich beispielsweise um eine ClickOnce-Anwendung, die von einem Entwickler des NuGet-Teams geschrieben wurde und eine visuelle Methode zum Erstellen und Überprüfen eines Pakets bietet. Sie steht unter „npe.codeplex.com“ zur Verfügung.

NuGet.exe

Da die meisten Paketautoren die Paketerstellung in ihre Buildprozesse integrieren möchten, lohnt es sich, eine weitere Methode näher zu betrachten, bei der das NuGet-Befehlszeilendienstprogramm verwendet wird. Sie müssen das Dienstprogramm nur einmal von „bit.ly/gmw54b“ herunterladen. Speichern Sie „NuGet.exe“ nach dem Herunterladen in einem Ordner, der Ihrer Umgebungsvariablen PATH hinzugefügt wurde. Für solche Dienstprogramme habe ich einen Ordner mit der Bezeichnung „utils“.

Da es sich bei „NuGet.exe“ um eine selbst aktualisierende ausführbare Datei handelt, brauchen Sie sie nur einmal pro Computer herunterzuladen. Führen Sie einfach den folgenden Befehl aus, um eine Onlineprüfung durchzuführen und NuGet auf die neueste Version zu aktualisieren, sofern verfügbar:

nuget update –self

Mit dem Befehlszeilentool kann der Onlinefeed wie die Paket-Manager-Konsole abgefragt werden. Beispiel: Verwenden Sie den folgenden Befehl, um nach allen Paketen mit „MVC“ zu suchen:

nuget list Mvc

Mithilfe von „NuGet.exe“ können Sie sogar ein Paket und Abhängigkeiten herunterladen und entpacken. Jedoch können Sie kein Projekt so ändern, dass es auf die heruntergeladenen Paketassemblys verweist oder die in einem Paket enthaltenen Windows PowerShell-Skripts ausführt.

Erstellen eines Pakets aus einem Projekt

Pakete enthalten zu 90 Prozent eine einzige Assembly (diese Statistik stammt von mir). Im folgenden Abschnitt wird ein einfacher Workflow zum Erstellen solcher Pakete mithilfe von „NuGet.exe“ anhand einer Projektdatei (wie einer CSPROJ- oder VBPROJ-Datei) behandelt.

Einzelheiten zum Erstellen komplexerer Pakete, wie einzelner Pakete mit Ausrichtung auf andere .NET Framework-Versionen, erhalten Sie auf der NuGet-Dokumentationswebsite unter „docs.nuget.org“.

Führen Sie die folgenden grundlegenden Schritte zum Erstellen eines Pakets aus:

1. Erstellen Sie ein Klassenbibliotheksprojekt.
2. Generieren Sie aus dem Projekt ein NuSpec-Manifest.
3. Aktualisieren Sie die Assemblymetadaten des Projekts.
4. Erstellen Sie das Paket mithilfe von „NuGet.exe“.

Erstellen eines Klassenbibliothekprojekts: Beginnen Sie mit einem Klassenbibliotheksprojekt, um eine Assembly freizugeben. Sie können in NuGet zwar mehrere Projekttypen packen, jedoch wird für die Freigabe von Code in der Regel eine Klassenbibliothek verwendet. Stellen Sie nach dem Erstellen des Pakets sicher, die Datei „AssemblyInfo.cs“ zu öffnen, um die Metadaten der Assembly zu aktualisieren.

Erstellen eines NuSpec-Manifests: Bei der NuSpec-Datei handelt es sich um ein Paketmanifest mit wichtigen Metadaten zum Paket wie dem Autor, einer Beschreibung und den Paketabhängigkeiten. Das NuSpec-Format kann einfach manuell erstellt werden, jedoch ist es praktischer, die Datei über den Befehl „spec“ zu generieren: Der Befehl muss im gleichen Verzeichnis wie die Projektdatei ausgeführt werden:

nuget spec

Da in diesem Fall der Befehl „spec“ die NuSpec-Datei aus einer Projektdatei generierte, enthält er für einige Metadaten Platzhalter (siehe Abbildung 7).

Abbildung 7: Generierte NuSpec-Datei

<?xml version="1.0"?>
<package xmlns=
  "https://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
  <metadata>
    <id>$id$</id>
    <version>$version$</version>
    <title>$title$</title>
    <authors>$author$</authors>
    <owners>$author$</owners>
    <licenseUrl>http://LICENSE_URL_HERE_OR_DELETE_THIS_LINE</licenseUrl>
    <projectUrl>http://PROJECT_URL_HERE_OR_DELETE_THIS_LINE</projectUrl>
    <iconUrl>http://ICON_URL_HERE_OR_DELETE_THIS_LINE</iconUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>$description$</description>
    <copyright>Copyright 2011</copyright>
    <tags>Tag1 Tag2</tags>
  </metadata>
</package>

Bearbeiten Sie die Felder mit den Platzhaltern nicht, sondern fügen Sie die korrekten Werte für die anderen Felder ein, wie „licenseUrl“, „projectUrl“, „iconUrl“ und Tags.

Aktualisieren der Assemblymetadaten des Projekts: Jede Assembly besitzt Metadaten mit Bezug auf die Assembly. NuGet kann diese Assemblymetadaten lesen und beim Erstellen eines Pakets im NuSpec-Manifest zusammenführen. Dadurch wird sichergestellt, dass diese Informationen zwischen dem Paket und der Assembly immer synchronisiert sind.

Wie oben erwähnt, befinden sich diese Informationen normalerweise in einer Datei mit dem Namen „AssemblyInfo.cs“. In der Tabelle in Abbildung 8 werden die Zuordnungen zwischen den Metadaten der Assembly und den NuSpec-Platzhalterwerten angezeigt.

Abbildung 8: NuSpec zugeordnete Assemblymetadaten

Token	Quelle
$id$	Assemblyname
$title$	Assemblytitel gemäß AssemblyTitleAttribute
$version$	Assemblyversion gemäß AssemblyVersionAttribute der Assembly
$author$	Das Unternehmen gemäß AssemblyCompanyAttribute
$description$	Die Beschreibung gemäß AssemblyDescriptionAttribute

Im Gegensatz zu anderen Feldern wird das Feld „$id$“ nicht aus einem Assemblyattribut extrahiert, sondern auf den Assemblynamen eingestellt.

Erstellen des Pakets: Führen Sie im selben Verzeichnis wie die Projektdatei und die NuSpec-Datei den folgenden Befehl zum Erstellen eines Pakets aus:

nuget pack ProjectName.csproj

Falls sich im selben Verzeichnis eine Projektdatei befindet, brauchen Sie den Projektdateinamen beim Ausführen des Befehls nicht zu verwenden.

Wenn Sie das Projekt noch nicht kompiliert haben, können Sie das Projekt vor dem Packen mithilfe des Flags „Build“ kompilieren. Hierdurch wird das Projekt vor dem Ausführen des Packbefehls zuerst kompiliert:

nuget pack ProjectName.csproj -Build

Dieser Befehl erzeugt eine Datei mit dem Namen „ProjectName.{version}.nupkg“, wobei „{version}“ dem Wert entspricht, der im AssemblyVersionAttribute angegeben wurde. Wenn zum Beispiel die Version 1.0.0 lautet, wird Ihr Paket „ProjectName.1.0.0.nupkg“ benannt. Sie können den Paket-Explorer verwenden, um das Paket anschließend zu überprüfen und sicherzustellen, dass es korrekt erstellt wurde.

Als freundliche Geste an die Entwickler, die das Paket installieren, können Sie das Flag „Symbols“ zum Erstellen eines Pakets mit Debuggersymbolen verwenden:

nuget pack ProjectName.csproj -Build -Symbols

Mit diesem Befehl wird zusätzlich zum Hauptpaket ein Symbolpaket erstellt. Dadurch können andere Benutzer, die das Paket installieren, beim Debuggen ihrer Anwendung den Paketcode ausführen.

Veröffentlichen eines Pakets

Nachdem Sie ein Paket erstellt haben, möchten Sie es sicherlich für die ganze Welt freigeben. Zu diesem Zweck ist in „NuGet.exe“ ein Befehl zum Veröffentlichen integriert. Vor dem Veröffentlichen müssen Sie unter „nuget.org“ ein Konto eröffnen.

Klicken Sie nach der Registrierung auf den Link zu Ihrem Konto, um den Zugriffsschlüssel abzurufen. Dieser Schlüssel ist wichtig, da er den Befehl „nuget.exe“ für den Katalog identifiziert und gleichzeitig ein widerrufbares Kennwort ist.

Speichern Sie den Schlüssel mithilfe des folgenden Befehls an einem sicheren Ort:

nuget setApiKey b688a925-0956-40a0-8327-ff2251cf5f9a

Veröffentlichen Sie ihr Paket anschließend mithilfe des Befehls „push“:

nuget push ProjectName.1.0.0.nupkg

Mit dem Befehl wird der API-Schlüssel vor dem Hochladen des Pakets anhand des Katalogs überprüft. Wenn Sie, wie oben besprochen, ein Symbolpaket erstellen, müssen Sie das Flag „Symbols“ zum Veröffentlichen des Pakets verwenden:

nuget push ProjectName.1.0.0.nupkg -Symbols

Geben Sie unbedingt den Namen des Hauptpakets und nicht des Symbolpakets an. Das passende Symbolpaket wird nach Konvention von dem Befehl ermittelt. Das Hauptpaket wird mithilfe des Befehls an den NuGet-Katalog und das Symbolpaket an das Partnerrepository „symbolsource.org“ gesendet.

Ausblick

In diesem Artikel habe ich gezeigt, wie mit NuGet nützliche Bibliotheken aus dem NuGet-Katalog abgerufen werden, um die Entwicklung neuer Projekte voranzutreiben. Für Unternehmen ist der Einsatz von NuGet beim Freigeben von Code für verschiedene Entwickler innerhalb einer Organisation von Vorteil.

Ich möchte aber noch mit einer Fehlannahme zur Zielgruppe von NuGet aufräumen, die sich hartnäckig hält, und zwar, dass NuGet nur für Webentwickler geeignet sei. Diese falsche Vorstellung ist möglicherweise auf die Integration von NuGet in die ASP.NET MVC 3-Version zurückzuführen. Hiermit möchte ich klarstellen, dass NuGet sich nicht nur an Webentwickler, sondern an alle Entwickler richtet. Neben anderen Projetkttypen werden Windows Phone, Silverlight und Windows Presentation Foundation unterstützt. Die Unterstützung wird in der Zukunft auf neue Projekttypen ausgedehnt.

Bei NuGet handelt es sich um ein communitygestütztes Open-Source-Projekt, das im Rahmen der Apache 2-Lizenz lizenziert wird. Das Projekt gehört der Outercurve Foundation, ist jedoch in Microsoft-Produkte integriert. Zu seinen wichtigsten Mitwirkenden zählen mehrere Microsoft-Entwickler.

Wenn Sie die NuGet-Entwicklung unterstützen möchten, besuchen Sie „nuget.codeplex.com“, um Informationen darüber zu erhalten, wie Sie sich beteiligen und möglicherweise sogar einen Beitrag zu NuGet leisten können.

In diesem Artikel konnten die Möglichkeiten von NuGet nur oberflächlich behandelt werden. Ausführlichere Informationen erhalten Sie auf der NuGet-Dokumentationswebsite unter „docs.nuget.org“ (das Team bemüht sich, die Website aktuell zu halten und nimmt gerne Beiträge zur Dokumentation an). Das Team ist auch im CodePlex-Diskussionsforum für das NuGet-Projekt aktiv und freut sich auf Ihre Fragen.    

Phil Haack ist leitender Programmmanager bei Microsoft im ASP.NET-Team, das an der Erstellung sinnvoller Produkte für Entwickler arbeitet. Während er sich mit vielen Themen im Zusammenhang mit ASP.NET befasst, sind ASP.NET MVC und NuGet-Paket-Manager seine beiden Hauptprojekte, die beide unter einer OSS-Lizenz freigegeben werden. In seiner Freizeit schreibt er in seinem Blog „haacked.com“ über Software und arbeitet an der Open-Source-Blog-Engine Subtext.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: David Fowler