Freigeben über

dotnet pack

  • Artikel

Dieser Artikel gilt für: ✔️ .NET Core 3.1 SDK und höher

Name

dotnet pack: Packt den Code in ein NuGet-Paket

Übersicht

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

Beschreibung

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 einem src-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.

Implizite Wiederherstellung

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.

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.

Workload manifest downloads

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.

Argumente

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.

Optionen

  • --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 auf net8.0 oder eine höhere Version festgelegt ist. Die Standardbuildkonfiguration ist Debug 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] und diag[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 Eigenschaften Version und VersionPrefix 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 und VersionSuffix $(VersionPrefix)-$(VersionSuffix)

    Wenn Sie --version-suffix verwenden möchten, geben Sie VersionPrefix und nicht Version in der Projektdatei an. Wenn VersionPrefix beispielsweise 0.1.2 ist und Sie --version-suffix rc.1 an dotnet pack übergeben, ist die Paketversion 0.1.2-rc.1.

    Wenn Version über einen Wert verfügt und Sie --version-suffix an dotnet pack übergeben, wird der für --version-suffix angegebene Wert ignoriert.

Beispiele

  • 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-Eigenschaft PackageVersion 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 und NuspecProperties finden Sie in den folgenden Ressourcen: