Freigeben über

Erstellen eines NuGet-Pakets mit der .NET CLI

Hinweis

Im Folgenden werden Befehlszeilenbeispiele unter Verwendung von Unix gezeigt. Der dotnet pack befehl wie hier gezeigt funktioniert auf Windows auf die gleiche Weise.

.NET Standard- und .NET Core-Bibliotheken sollen als NuGet-Pakete verteilt werden. Dies ist in der Tat, wie alle .NET Standard-Bibliotheken verteilt und verbraucht werden. Dies erfolgt am einfachsten mit dem dotnet pack Befehl.

Stellen Sie sich vor, Sie haben gerade eine tolle neue Bibliothek geschrieben, die Sie über NuGet verteilen möchten. Sie können ein NuGet-Paket mit plattformübergreifenden Tools erstellen, um genau das zu tun! Im folgenden Beispiel wird davon ausgegangen, dass eine Bibliothek mit dem Namen SuperAwesomeLibrary auf das Ziel ausgerichtet ist netstandard1.0.

Wenn Sie transitive Abhängigkeiten haben, d. h. ein Projekt, das von einem anderen Paket abhängt, stellen Sie sicher, dass Pakete für die gesamte Lösung mit dem dotnet restore Befehl wiederhergestellt werden, bevor Sie ein NuGet-Paket erstellen. Andernfalls funktioniert der dotnet pack Befehl nicht ordnungsgemäß.

Sie müssen dotnet restore nicht ausführen, da der Befehl implizit von allen Befehlen ausgeführt wird, die eine Wiederherstellung erfordern. Zu diesen zählen z. B. dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish und dotnet pack. Verwenden Sie die Option --no-restore, um die implizite Wiederherstellung zu deaktivieren.

In bestimmten Fällen eignet sich der dotnet restore-Befehl dennoch. Dies ist etwa bei Szenarios der Fall, in denen die explizite Wiederherstellung sinnvoll ist. Beispiele hierfür sind Continuous Integration-Builds in Azure DevOps Services oder Buildsysteme, die den Zeitpunkt für die Wiederherstellung explizit steuern müssen.

Informationen zum Verwalten von NuGet-Feeds finden Sie in der dotnet restoreDokumentation.

Nachdem Sie sichergestellt haben, dass Pakete wiederhergestellt werden, können Sie zu dem Verzeichnis navigieren, in dem sich eine Bibliothek befindet:

cd src/SuperAwesomeLibrary

Dann ist es nur ein einzelner Befehl über die Befehlszeile:

dotnet pack

Ihr Ordner "/bin/Debug " sieht nun wie folgt aus:

$ ls bin/Debug
netstandard1.0/
SuperAwesomeLibrary.1.0.0.nupkg
SuperAwesomeLibrary.1.0.0.symbols.nupkg

Dies erzeugt ein Paket, das debuggiert werden kann. Wenn Sie ein NuGet-Paket mit Versionsbinärdateien erstellen möchten, müssen Sie lediglich den --configuration Schalter (oder -c) hinzufügen und als Argument verwenden release .

dotnet pack --configuration release

Ihr Ordner "/bin " verfügt jetzt über einen Releaseordner , der Ihr NuGet-Paket mit Veröffentlichungsbinärdateien enthält:

$ ls bin/release
netstandard1.0/
SuperAwesomeLibrary.1.0.0.nupkg
SuperAwesomeLibrary.1.0.0.symbols.nupkg

Und jetzt haben Sie die erforderlichen Dateien, um ein NuGet-Paket zu veröffentlichen!

Verwechseln dotnet pack Sie nicht mit dotnet publish

Es ist wichtig zu beachten, dass an keinem Punkt der dotnet publish Befehl beteiligt ist. Der dotnet publish Befehl dient zum Bereitstellen von Anwendungen mit allen abhängigkeiten im selben Bundle – nicht zum Generieren eines NuGet-Pakets, das über NuGet verteilt und genutzt werden soll.

Siehe auch