dotnet pack
Dieser Artikel gilt für: ✔️ .NET Core 3.1 SDK und höher
dotnet pack
: Packt den Code in ein NuGet-Paket
dotnet pack [<PROJECT>|<SOLUTION>] [--artifacts-path <ARTIFACTS_DIR>]
[-c|--configuration <CONFIGURATION>] [--force]
[--include-source] [--include-symbols] [--interactive]
[--no-build] [--no-dependencies] [--no-restore] [--nologo]
[-o|--output <OUTPUT_DIRECTORY>] [--runtime <RUNTIME_IDENTIFIER>]
[-s|--serviceable] [--tl:[auto|on|off]] [-v|--verbosity <LEVEL>]
[--version-suffix <VERSION_SUFFIX>]
dotnet pack -h|--help
Der Befehl dotnet pack
erstellt das Projekt und NuGet-Pakete. Das Ergebnis dieses Befehls ist ein NuGet-Paket (d. h., eine NUPKG-Datei).
Wenn Sie ein Paket generieren möchten, das die Debugsymbole enthält, stehen Ihnen zwei Optionen zur Verfügung:
--include-symbols
: Es erstellt das Symbolpaket.--include-source
: Es erstellt das Symbolpaket mit einemsrc
-Ordner, der die Quelldateien enthält.
NuGet-Abhängigkeiten des gepackten Projekts werden der Datei nuspec hinzugefügt. Sie werden ordnungsgemäß aufgelöst, wenn das Paket installiert wird. Wenn das gepackte Projekt Verweise auf andere Projekte enthält, werden die anderen Projekte nicht in das Paket aufgenommen. Derzeit benötigen Sie ein Paket pro Projekt, wenn Sie Abhängigkeiten zwischen Projekten haben.
dotnet pack
erstellt standardmäßig zuerst das Projekt. Wenn Sie dieses Verhalten vermeiden möchten, übergeben Sie die Option --no-build
. Diese Option ist bei Buildszenarios der Continuous Integration (CI) oft hilfreich, bei denen Sie wissen, dass der Code kürzlich erstellt wurde.
Hinweis
In einigen Fällen kann die implizierte Kompilierung nicht ausgeführt werden. Dies kann passieren, wenn GeneratePackageOnBuild
festgelegt ist, um eine zyklische Abhängigkeit zwischen Build und Paketzielen zu vermeiden. Die Kompilierung kann auch fehlschlagen, wenn eine gesperrte Datei oder ein anderes Problem vorliegt.
Sie können dem dotnet pack
-Befehl MSBuild-Eigenschaften für den Packvorgang bereitstellen. Weitere Informationen finden Sie unter Zieleigenschaften für nuget pack und in der MSBuild-Befehlszeilenreferenz. Der Abschnitt Beispiele enthält Informationen darüber, wie der MSBuild-Parameter -p
für verschiedene Szenarios verwendet wird.
Hinweis
Webprojekte können nicht gepackt werden.
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 restore
Dokumentation.
Dieser Befehl unterstützt die dotnet restore
-Optionen, wenn sie in der Langform (z. B. --source
) übergeben werden. Optionen in Kurzform wie z.B. -s
werden nicht unterstützt.
Wenn Sie diesen Befehl ausführen, wird im Hintergrund ein asynchroner Download initiiert, der Ankündigungsmanifeste für Workloads herunterlädt. Wenn der Download noch ausgeführt wird, wenn der Befehl abgeschlossen ist, wird der Download angehalten. Weitere Informationen finden Sie unter Ankündigungsmanifeste.
PROJECT | SOLUTION
Das Projekt oder die Projektmappe, die gepackt werden soll. Es ist entweder ein Pfad zu einer CSPROJ-Datei, VBPROJ-Datei, FSPROJ-Datei, Projektmappendatei oder einem Verzeichnis. Ist dieses Argument nicht angegeben, sucht der Befehl im aktuellen Verzeichnis nach einem Projekt oder einer Projektmappendatei.
--artifacts-path <ARTIFACTS_DIR>
Alle Buildausgabedateien des ausgeführten Befehls werden in Unterordnern unter dem angegebenen Pfad, getrennt durch Das Projekt, verschoben. Weitere Informationen finden Sie unter "Artifacts Output Layout". Verfügbar ab dem .NET 8 SDK.
-c|--configuration <CONFIGURATION>
Legt die Buildkonfiguration fest. Wenn Sie mit dem .NET 8 SDK oder einer höheren Version entwickeln, verwendet der Befehl standardmäßig die
Release
Konfiguration für Projekte, deren TargetFramework aufnet8.0
oder eine höhere Version festgelegt ist. Die Standardbuildkonfiguration istDebug
für frühere Versionen des SDK und für frühere Zielframeworks vorgesehen. Sie können die Standardeinstellung in den Projekteinstellungen oder mithilfe dieser Option außer Kraft setzen. Weitere Informationen finden Sie unter "dotnet publish" verwendet die Releasekonfiguration und "dotnet pack" verwendet die Release-Konfiguration.
--force
Erzwingt das Auflösen aller Abhängigkeiten, auch wenn die letzte Wiederherstellung erfolgreich war. Dieses Flag anzugeben, entspricht dem Löschen der Datei project.assets.json.
-?|-h|--help
Gibt eine Beschreibung zur Verwendung des Befehls aus.
--include-source
Schließt neben den regulären NuGet-Paketen im Ausgabeverzeichnis auch die NuGet-Pakete der Debugsymbole ein. Die Quelldateien befinden sich im
src
-Ordner im Symbolpaket.--include-symbols
Schließt neben den regulären NuGet-Paketen im Ausgabeverzeichnis auch die NuGet-Pakete der Debugsymbole ein.
--interactive
Ermöglicht dem Befehl, anzuhalten und auf Benutzereingaben oder Aktionen zu warten. Beispielsweise, um die Authentifizierung abzuschließen. Verfügbar seit .NET Core 3.0 SDK.
--no-build
Erstellt das Projekt nicht vor dem Packen. Zudem wird das Flag
--no-restore
implizit festgelegt.--no-dependencies
Ignoriert Verweise zwischen Projekten und stellt nur das zum Erstellen angegebene Stammprojekt wieder her.
--no-restore
Führt keine implizite Wiederherstellung aus, wenn der Befehl ausgeführt wird.
--nologo
Unterdrückt die Anzeige von Startbanner und Copyrightmeldung.
-o|--output <OUTPUT_DIRECTORY>
Platziert die erstellten Pakete in das angegebene Verzeichnis.
.NET 7.0.200 SDK
Wenn Sie im SDK 7.0.200 beim Ausführen dieses Befehls für eine Projektmappe die
--output
-Option angeben, gibt die CLI einen Fehler aus. Dies ist eine Regression und wurde in Version 7.0.201 und höheren Versionen des .NET SDK behoben.
--runtime <RUNTIME_IDENTIFIER>
Gibt die Ziellaufzeit an, für die Pakete wiederhergestellt werden sollen Eine Liste der Runtime-IDs (RIDs) finden Sie unter RID-Katalog.
-s|--serviceable
Legt das zu verarbeitende Flag im Paket fest. Weitere Informationen finden Sie unter .NET Blog: .NET Framework 4.5.1 unterstützt Microsoft-Sicherheitsupdates für .NET-NuGet-Bibliotheken.
--tl:[auto|on|off]
Gibt an, ob die Terminalprotokollierung für die Buildausgabe verwendet werden soll. Der Standardwert ist
auto
, mit den zunächst die Umgebung überprüft wird, bevor die Terminalprotokollierung aktiviert wird. Die Umgebungsprüfung testet, ob das Terminal moderne Ausgabefeatures verwenden kann und keine umgeleitete Standardausgabe verwendet, bevor die neue Protokollierung aktiviert wird.on
überspringt die Umgebungsprüfung und aktiviert die Terminalprotokollierung.off
überspringt die Umgebungsprüfung und verwendet die Standardkonsolenprotokollierung.Die Terminalprotokollierung zeigt die Wiederherstellungsphase gefolgt von der Buildphase an. Während jeder Phase werden am unteren Rand des Terminals die derzeit erstellten Projekte angezeigt. Für jedes erstellte Projekt wird sowohl das MSBuild-Ziel für den Build als auch die Zeit ausgegeben, die für dieses Ziel aufgewendet wurde. Sie können diese Informationen durchsuchen, um mehr über den Build zu erfahren. Wenn die Erstellung eines Projekts abgeschlossen ist, wird ein einzelner Abschnitt „Build abgeschlossen“ geschrieben, in dem Folgendes erfasst wird:
- Der Name des erstellten Projekts
- Das Zielframework (bei mehreren Zielen)
- Der Status dieses Builds
- Die primäre Ausgabe dieses Builds (als Link)
- Alle für dieses Projekt generierten Diagnoseinformationen
Diese Option ist ab .NET 8 verfügbar.
-v|--verbosity <LEVEL>
Legt den Ausführlichkeitsgrad für den Befehl fest. Zulässige Werte sind
q[uiet]
,m[inimal]
,n[ormal]
,d[etailed]
unddiag[nostic]
. Weitere Informationen finden Sie unter LoggerVerbosity.
--version-suffix <VERSION_SUFFIX>
Definiert den Wert für die MSBuild Eigenschaft
VersionSuffix
. Die Auswirkung dieser Eigenschaft auf die Paketversion hängt von den Werten der EigenschaftenVersion
undVersionPrefix
ab, wie in der folgenden Tabelle gezeigt:Eigenschaften mit Werten Paketversion Keine 1.0.0
Version
$(Version)
Nur VersionPrefix
$(VersionPrefix)
Nur VersionSuffix
1.0.0-$(VersionSuffix)
VersionPrefix
undVersionSuffix
$(VersionPrefix)-$(VersionSuffix)
Wenn Sie
--version-suffix
verwenden möchten, geben SieVersionPrefix
und nichtVersion
in der Projektdatei an. WennVersionPrefix
beispielsweise0.1.2
ist und Sie--version-suffix rc.1
andotnet pack
übergeben, ist die Paketversion0.1.2-rc.1
.Wenn
Version
über einen Wert verfügt und Sie--version-suffix
andotnet pack
übergeben, wird der für--version-suffix
angegebene Wert ignoriert.
Packt das Projekt im aktuellen Verzeichnis:
dotnet pack
Packt das
app1
-Projekt:dotnet pack ~/projects/app1/project.csproj
Packt das Projekt im aktuellen Verzeichnis, und platziert die erstellten Pakete in den
nupkgs
-Ordner:dotnet pack --output nupkgs
Packt das Projekt im aktuellen Verzeichnis in den
nupkgs
-Ordner und überspringt den Buildschritt:dotnet pack --no-build --output nupkgs
Mit dem Versionssuffix des Projekts, das als
<VersionSuffix>$(VersionSuffix)</VersionSuffix>
in der .csproj-Datei konfiguriert ist, packen Sie das aktuelle Projekt, und aktualisieren Sie die resultierende Paketversion mit dem angegebenen Suffix:dotnet pack --version-suffix "ci-1234"
Legen Sie die Paketversion auf
2.1.0
mithilfe der MSBuild-EigenschaftPackageVersion
fest.dotnet pack -p:PackageVersion=2.1.0
Packen Sie das Projekt für ein bestimmtes Zielframework:
dotnet pack -p:TargetFrameworks=net45
Packen Sie das Projekt, und verwenden Sie eine bestimmte Laufzeit (Windows) für den Wiederherstellungsvorgang:
dotnet pack --runtime win-x64
Packen Sie das Projekt mithilfe einer NUSPEC-Datei:
dotnet pack ~/projects/app1/project.csproj -p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget
Informationen zur Verwendung von
NuspecFile
,NuspecBasePath
undNuspecProperties
finden Sie in den folgenden Ressourcen:
Feedback zu .NET
.NET ist ein Open Source-Projekt. Wählen Sie einen Link aus, um Feedback zu geben: