NuGet Library Package Manager (NuGet)
Eintrag zuletzt aktualisiert am: 21.10.2023
Der NuGet Library Package Manager (kurz: NuGet) ist eine Paketmanagementlösung von Microsoft. Pakete werden auf NuGet-Servern (Repositories) zum Abruf bereitgestellt. Von einem Paket kann es beliebig viele Versionen geben. Man ruft die aktuellste oder eine bestimmte Version ab. Ein Paket beinhalten ein oder mehrere Assemblies (
DLLs) oder andere Artekfakte, z.B.
JavaScript, die sich zur Verwendung in verschiedenen Projekten eignen. Ein Paket kann Assemblies in mehreren Varianten für verschiedene .NET-Varianten und NET-Versionen beinhalten.
Bei Nuget geht es nicht um die Erweiterung der
Visual Studio-
Entwicklungsumgebung, sondern um die Installation von zusätzlichen
Komponenten für .NET-Projekte, die über den Lieferumfang von
.NET Frameworks und .NET Core hinausgehen. Es gibt inzwischen viele hundert solcher Zusatzkomponenten sowohl von Microsoft als auch von Drittanbietern bzw. der
Open Source-Gemeinde.
Bedeutung des Wortes NuGet
"Nu" - Dieses Wort steht für "Neu" oder "Aktualisiert".
"Get" - Dieses Wort verdeutlicht den Prozess des Abrufens von Bibliotheken und Paketen
Relevanz von NuGet
einzelne Zusatzpakete von Microsoft
schnell akzeptiert von Community / Drittanbietern
- Seit 2016 sehr wichtig als integraler Teil von .NET Core
Zunächst war auch das heutige
.NET SDK in Pakete zerteilt
Das hat Microsoft mit der Zeit wieder aufgehoben: Viele Assemblies Teil des SDK
Weiterhin aber einzelne moderne .NET-Funktionen nur per NuGet
z.B.
Entity Framework Core
z.B. Microsoft.Extensions.DependencyInjection
z.B. Microsoft.AspNetCore.Authorization
NuGet-Server, die Pakete zum Abruf bereitstellen
- Öffentlicher Server: NuGet.org von Microsoft
- Private Server in der Cloud, z.B.
MyGet.org von Assembla (Teil von Idera Inc.)
Einfaches Netzlaufwerk oder
NuGet-Prozess
https://docs.microsoft.com/de-de/nuget/hosting-packages/nuget-server
NuGet-Clients zum Abruf von Paketen
Es gibt verschiedene Clients, die Pakete abrufen können:
Visual Studio enthält sowohl eine grafische Benutzeroberfläche (Package Manager UI) für die
Nuget-Paketverwaltung als auch das PowerShell-basierte Konsolenfenster "Nuget
Package Manager Console" (
NPMC). Nicht bei
Visual Studio mitgeliefert wird aber eine eigenständige Konsolenanwendung zur Paketverwaltung, die man außerhalb von
Visual Studio nutzen könnte.
Es gibt eine solche Konsolenanwendung mit Namen nuget.exe (alias "Nuget
Command Line Interface", kurz: "Nuget CLI") für Windows auf [
https://www.nuget.org/downloads]. Die aktuelle Version von nuget.exe bekommt man immer unter [
https://dist.nuget.org/win-x86-commandline/latest/nuget.exe]. Den Quellcode findet man auf Github unter [
https://github.com/nuget/nuget.client].
Hintergründe
Klassischerweise lädt man Zusatzkomponenten von irgendeiner Website herunter. Man führt eine Setup.exe aus oder entpackt ein ZIP-Paket. Dadurch erhält man eine oder mehrere Assemblies, die man dann im
Visual Studio-Projekt referenziert. Manchmal findet man gerade nach der Ausführung eines Setup-Pakets diese Assemblies gar nicht so leicht auf der eigenen Festplatte. Manchmal muss man zum Funktionieren der
Komponente noch Einträge in der
Konfigurationsdatei vornehmen. Manchmal muss man vorher erst andere
Komponenten hinzufügen, damit eine
Komponente funktionieren kann.
Diesen Vorgang vereinfacht NuGet. NuGet definiert Pakete, die die für eine Zusatzkomponente benötigten Assemblies und Konfigurationseinstellungen enthalten. Zudem kann ein NuGet-Paket Abhängigkeiten zu anderen Paket definieren.
Der Dialog „Manage NuGet Packages“, den man unter „Tools/Library Package Manager“ oder im Kontextmenü eines Projekts im Solution Explorer findet, bietet eine Online-Suche von Zu-satzkomponenten. Dabei wird im Standard auf www.nuget.org (mit
Webservices
https://nuget.org/api/v2/) gesucht. Man kann aber einen eigenen NuGet-Server betreiben und diesen unter Tools/Package Mana-ger/Package Sources in
Visual Studio registrieren.
Alternativ zu dem NuGet-Dialog kann man die NuGet-Konsole verwenden. Diese basiert auf der
Windows PowerShell und bietet für NuGet das
Commandlet „Install-Package“. Durch den Parameter –Version kann man eine bestimmte Version einer Zusatzkomponente installieren. Durch den Parameter –IncludePrelease (abgekürzt –pre) kann man erzwingen, dass auch eine eventuell vorhandene Vorab-Version (
CTP, Alpha, Beta,
Razor Component) einer Zusatzkomponente installiert wird.
Die NuGet-Konsole in
Visual Studio bietet alle Befehle der
Windows PowerShell. Erforschen Sie die Möglichkeiten mit „Get-Command“. Wünschen Sie sich mehr Informationen zu den Befehlen? Geben Sie „Get-Help Befehlsname –full“ ein. Wünschen Sie, dass dieses Buch die Befehle beschreibt? Bitte bedenken Sie, dass es Bücher zur PowerShell mehrere Hundert Seiten dick sind!
Durch die Installation eines NuGet-Pakets werden die benötigten Assemblies dem aktuellen Projekt (oder wahlweise allen Projekten in einer Projektmappe) hinzugefügt. Optional werden die
Konfigurationsdateien (app.config oder
web.config) geändert.
Ein
Nuget-Paket ist eine Datei mit der Dateinamenserweiterung .
nupkg. Dahinter verbirgt sich eine ZIP-Datei. Zentraler Punkt in dem Archiv ist eine Datei mit der Dateinamenserweiterung .nuspec, in der
Metadaten des Pakets und Abhängigkeiten beschrieben werden. Die installierten Pakete werden im Verzeichnis „Packages“ unterhalb des Projektmappenverzeichnisses sowie in zentralen NuGet-Cache im Benutzerprofil (AppData/Local/NuGet/Cache) abgelegt.
Mit Hilfe des Cache-Verzeichnisses können Sie auch bereits einmal heruntergeladene NuGet-Pakete installueren, wenn Sie offline sind (z.B. install-package
nHibernate -Source C:\Users\HS\AppData\Local\NuGet\Cache)
Listing 1: Nuget-Paket-Spezifikation für das NuGet-Paket „Nhibernate“
<?xml version="1.0"?>
<package xmlns="
http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>Nhibernate</id>
<version>3.3.1.4000</version>
<authors>Nhibernate community, Hibernate community</authors>
<owners>Nhibernate community, Hibernate community</owners>
<projectUrl>
http://www.nhforge.org</projectUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Nhibernate is a mature, open source object-relational mapper for the .NET framework. It is actively developed, fully featured and used in thousands of suc-cessful projects.</description>
<summary>Nhibernate is a mature, open source object-relational mapper for the .NET framework. It is actively developed, fully featured and used in thousands of successful projects.</summary>
<language>en-US</language>
<tags>
ORM, DataBase,
DAL, ObjectRelationalMapping</tags>
<dependencies>
<dependency id="Iesi.Collections" version="3.2.0.4000" />
</dependencies>
</metadata>
</package>
Listing 1: Nuget-Paket-Spezifikation für das NuGet-Paket „EntityFramework“
<?xml version="1.0"?>
<package xmlns="
http://schemas.microsoft.com/packaging/2011/10/nuspec.xsd">
<metadata>
<id>EntityFramework</id>
<version>5.0.0-rc</version>
<authors>Microsoft</authors>
<owners>Microsoft</owners>
<licenseUrl>
http://go.microsoft.com/fwlink/?LinkId=248959</licenseUrl>
<projectUrl>
http://go.microsoft.com/fwlink/?LinkId=248960</projectUrl>
<requireLicenseAcceptance>true</requireLicenseAcceptance>
<description>Entity Framework is Microsoft's recommended data access technology for new applications.</description>
<summary>Entity Framework is Microsoft's recommended data access technology for new applications.</summary>
<language>en-US</language>
<frameworkAssemblies>
<frameworkAssembly assemblyName="
System.Data.Entity" targetFramework="" />
<frameworkAssembly assemblyName="
System.ComponentModel.Data
Annotations" targetFra-mework="" />
</frameworkAssemblies>
</metadata>
</package>
Nuget in .NET Core
Die Bedeutung des
Komponentenportal NuGet.org ist in den letzten Jahren immer weiter gestiegen. Inzwischen verteilt Microsoft einige .NET-Erweiterungen nur noch auf diesem Wege. In der neuen .NET Core-Welt wird NuGet auch zum Distributionskanal für das Framework selbst. Anders als das bisherige große
.NET Framework wird das .NET Core-Framework nicht mehr über ein Windows-Installer-Setup installieren. Es reicht, einige EXE-Dateien und
DLLs herunterzuladen. Diese Dateien sollen im Standard im lokalen Anwendungsverzeichnis betrieben werden, sodass eine Koexistenz beliebig vieler .NET Core-Versionen auf einem Rechner möglich ist. Das ist insbesondere für geteilte Server und die Cloud sehr hilfreich. Bereits Anfang dieses Jahres hatte Microsoft einen Mechanismus eingeführt, mit dem der Konzern Aktualisierungen von
Nuget-Paketen über Windows Update verteilen kann. Dabei me
rkt sich der
CLR-Loader, welche Assemblies er geladen hat. Windows Update packt dann sicherheitsrelevante Aktualisierungen in den
Global Assembly Cache (
GAC) und sorgt per Binding Redirect dafür, dass diese Aktualisierungen statt der lokalen Assemblies im Anwendungsverzeichnis verwendet werden.
Neben dem .NET-Kern und mit unzähligen optionalen Erweiterungspaketen will Microsoft aber auch Meta-Pakete bereitstellen. Die Meta-Pakete definieren einen Satz von
Komponenten, die Microsoft zusammen getestet hat. Damit spricht Microsoft diejenigen Unternehmen an, die nicht die Aufgabe auf sich nehmen wollen, zueinander passende
Komponenten zusammenzustellen. Meta-Pakete wird es aber nur wenige Mal im Jahr geben, während die einzelnen
Komponenten sich tendenziell sehr agil, das heißt in kurzen Veröffentlichungszyklen weiterentwickeln werden.
Um diese Pläne praktikabel zu machen, will Microsoft die zur Beschreibung von
Nuget-Paketen verwendete
XML-Syntax „Nuspec“ erweitern, damit Plattform-Voraussetzungen und komplexe Paketabhängigkeiten zukünftig auch ohne Einsatz von Skripten definierbar sind. Aus der Sicht des Nutzers soll die Einbindung von Paketen in Projekte beschleunigt werden. Geplant ist auch, dass NuGet-Pakete direkt als Referenzen in
Visual Studio erscheinen und aus
Visual Studio-Projekten direkt NuGet-Pakete erzeugt werden können. Die vollständige Integration in NuGet wird es aber nach heutigem Stand zunächst nur mit
ASP.NET Core gibt. Die App-Entwicklung wird im ersten Schritt noch klassische Wege gehen. Auch andere Abweichungen gibt es in
ASP.NET Core. So wird
ASP.NET Core zum Beispiel statt der bisherigen
XML-
Konfigurationsdateien den Großteil der Konfigurationsinformationen im
JSON-Format ablegen. Andere Konfigurationsformate sind aber möglich, sodass das Konfigurationssystem ebenso wie viele andere Teile von
ASP.NET Core im Sinne der
Dependency Injection austauschbar sind.