dotnet pack

  • Article

Cet article s’applique à :✔️ SDK .NET Core 3.1 et versions ultérieures

Nom

dotnet pack : Place le code dans un package NuGet.

Synopsis

dotnet pack [<PROJECT>|<SOLUTION>] [-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

Description

La commande dotnet pack génère le projet et crée les packages NuGet. Le résultat de cette commande est un package NuGet (c’est-à-dire un fichier .nupkg).

Si vous souhaitez générer un package qui contient les symboles de débogage, vous disposez de deux options :

  • --include-symbols - le package de symboles est créé.
  • --include-source - le package de symboles avec à l’intérieur un src dossier contenant les fichiers sources est créé.

Les dépendances NuGet du projet empaqueté sont ajoutées dans le fichier .nuspec, pour pouvoir être correctement résolues lors de l’installation du package. Si le projet empaqueté contient des références à d’autres projets, les autres projets ne sont pas inclus dans le package. Actuellement, vous devez disposer d’un package par projet si vous avez des dépendances entre projets.

Par défaut, dotnet pack génère d’abord le projet. Pour éviter ce comportement, passez l’option --no-build. Cette option s’avère souvent utile dans les scénarios de build d’intégration continue (CI), pour lesquels vous savez que le code a déjà été créé.

Notes

Dans certains cas, la génération implicite ne peut pas être effectuée. Cela peut se produire lorsque GeneratePackageOnBuild est défini, pour éviter une dépendance cyclique entre les cibles de build et de pack. Le build peut également échouer en cas de fichier verrouillé ou d’un autre problème.

Vous pouvez fournir des propriétés MSBuild à la commande dotnet pack pour le processus de compression. Pour plus d’informations, consultez Propriétés cibles NuGet et Informations de référence sur la ligne de commande MSBuild. La section Exemples montre comment utiliser le commutateur MSBuild -p pour deux scénarios différents.

Notes

Les projets web ne peuvent pas être ajoutés dans un package.

Restauration implicite

Vous n’avez pas besoin d’exécuter dotnet restore, car il est exécuté implicitement par toutes les commandes qui nécessitent une restauration pour se produire, comme dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish et dotnet pack. Pour désactiver la restauration implicite, utilisez l’option --no-restore .

La commande dotnet restore est toujours utile dans certains scénarios où la restauration explicite est logique, comme les builds d’intégration continue dans Azure DevOps Services ou dans les systèmes de génération qui doivent contrôler explicitement le moment où la restauration se produit.

Pour plus d’informations sur la gestion des flux NuGet, consultez la documentation dotnet restore.

Cette commande prend en charge les options de dotnet restore quand elles sont transférées sous leur forme longue (par exemple --source). Les options sous forme abrégée, comme -s, ne sont pas prises en charge.

Téléchargement de manifestes de charge de travail

Lorsque vous exécutez cette commande, elle lance en arrière-plan un téléchargement asynchrone des manifestes publicitaires des charges de travail. Si le téléchargement est toujours en cours lorsque cette commande se termine, celui-ci est arrêté. Pour plus d’informations, consultez Manifestes publicitaires.

Arguments

PROJECT | SOLUTION

Le projet ou la solution à empaqueter. Il s’agit d’un chemin d’accès à un fichier csproj, vbproj ou fsproj, ou à un fichier ou répertoire solution. Si aucun fichier n’est spécifié, la commande recherche un fichier ou solution projet dans le répertoire actif.

Options

  • -c|--configuration <CONFIGURATION>

    Définit la configuration de build. Si vous développez avec le Kit de développement logiciel (SDK) .NET 8 ou une version ultérieure, la commande utilise la Release configuration par défaut pour les projets dont TargetFramework est défini net8.0 sur ou une version ultérieure. La configuration de build par défaut concerne Debug les versions antérieures du Kit de développement logiciel (SDK) et pour les frameworks cibles antérieurs. Vous pouvez remplacer la valeur par défaut dans les paramètres du projet ou à l’aide de cette option. Pour plus d’informations, consultez « dotnet publish » utilise la configuration release et « dotnet pack » utilise la configuration release.

  • --force

    Force la résolution de toutes les dépendances même si la dernière restauration a réussi. Définir cet indicateur revient à supprimer le fichier project.assets.json.

  • -?|-h|--help

    Imprime une description de l’utilisation de la commande.

  • --include-source

    Inclut les symboles de débogage des packages NuGet en plus des packages NuGet standard dans le répertoire de sortie. Les fichiers sources sont inclus dans le dossier src dans le package de symboles.

  • --include-symbols

    Inclut les symboles de débogage des packages NuGet en plus des packages NuGet standard dans le répertoire de sortie.

  • --interactive

    Permet à la commande de s’arrêter et d’attendre une action ou une entrée utilisateur. Par exemple, pour effectuer une authentification. Option disponible à partir du kit SDK .NET Core 3.0.

  • --no-build

    Ne génère pas le projet avant de créer le package. L’indicateur --no-restore est également défini implicitement.

  • --no-dependencies

    Ignore les références entre projets et restaure uniquement le projet racine.

  • --no-restore

    N’effectue pas de restauration implicite à l’exécution de la commande.

  • --nologo

    N’affiche pas la bannière de démarrage ni le message de copyright.

  • -o|--output <OUTPUT_DIRECTORY>

    Place les packages générés dans le répertoire spécifié.

    • Kit SDK .NET 7.0.200

      Si, dans le kit de développement logiciel (SDK) 7.0.200, vous spécifiez l’option --output lors de l’exécution de cette commande sur une solution, l’interface CLI émet une erreur. Cette régression a été corrigée dans la version 7.0.201 et les versions ultérieures du kit SDK .NET.

  • --runtime <RUNTIME_IDENTIFIER>

    Spécifie le runtime cible pour lequel restaurer les packages. Pour connaître les identificateurs de runtime, consultez le catalogue des identificateurs de runtime.

  • -s|--serviceable

    Définit l’indicateur d’un état pouvant faire l’objet d’une maintenance dans le package. Pour plus d’informations, consultez Blog .NET : .NET Framework 4.5.1 prend en charge les mises à jour de sécurité de Microsoft pour les bibliothèques NuGet .NET.

  • --tl:[auto|on|off]

    Spécifie si l’enregistreur d’événements de terminal doit être utilisé pour la sortie de build. La valeur par défaut est auto, qui vérifie d’abord l’environnement avant d’activer la journalisation du terminal. La vérification de l’environnement vérifie que le terminal est capable d’utiliser des fonctionnalités de sortie modernes et n’utilise pas une sortie standard redirigée avant d’activer le nouvel enregistreur d’événements. on ignore la vérification de l’environnement et active la journalisation du terminal. off ignore la vérification de l’environnement et utilise l’enregistreur d’événements de console par défaut.

    L’enregistreur d’événements de terminal affiche la phase de restauration suivie par la phase de génération. Au cours de chaque phase, les projets en cours de génération apparaissent en bas du terminal. Chaque projet en cours de génération génère à la fois la cible MSBuild en cours de génération et le temps consacré à cette cible. Vous pouvez rechercher ces informations pour en savoir plus sur la génération. Lorsque la génération d’un projet est terminée, une unique section « build terminée » est écrite et capture :

    • Le nom du projet généré.
    • Le framework cible (si plusieurs cibles).
    • L’état de cette build.
    • La sortie principale de cette génération (qui est un lien hypertexte).
    • Les diagnostics générés pour ce projet.

    Cette option est disponible à partir de .NET 8.

  • -v|--verbosity <LEVEL>

    Définit le niveau de détail de la commande. Les valeurs autorisées sont q[uiet], m[inimal], n[ormal], d[etailed] et diag[nostic]. Pour plus d’informations, consultez LoggerVerbosity.

  • --version-suffix <VERSION_SUFFIX>

    Définit la valeur de la propriété MSBuild VersionSuffix. L’effet de cette propriété sur la version du package dépend des valeurs des propriétés Version et VersionPrefix, comme indiqué dans le tableau suivant :

    Propriétés avec des valeurs Version du package
    None 1.0.0
    Version $(Version)
    VersionPrefix uniquement $(VersionPrefix)
    VersionSuffix uniquement 1.0.0-$(VersionSuffix)
    VersionPrefix et VersionSuffix $(VersionPrefix)-$(VersionSuffix)

    Si vous souhaitez utiliser --version-suffix, spécifiez VersionPrefix et non Version dans le fichier projet. Par exemple, si VersionPrefix est 0.1.2 et que vous faites passer --version-suffix rc.1 à dotnet pack, la version du package sera 0.1.2-rc.1.

    Si Version a une valeur et que vous faites passer --version-suffix à dotnet pack, la valeur spécifiée pour --version-suffix est ignorée.

Exemples

  • Empaquetez le projet dans le répertoire actif :

    dotnet pack

  • Empaqueter le projet app1 :

    dotnet pack ~/projects/app1/project.csproj

  • Empaqueter le projet dans le répertoire actif et placer les packages résultants dans le dossier nupkgs :

    dotnet pack --output nupkgs

  • Empaqueter le projet dans le répertoire actif du dossier nupkgs et ignorer l’étape de génération :

    dotnet pack --no-build --output nupkgs

  • Avec le suffixe de version du projet configuré comme <VersionSuffix>$(VersionSuffix)</VersionSuffix> dans le fichier .csproj, empaqueter le projet actif et mettre à jour la version du package obtenue avec le suffixe donné :

    dotnet pack --version-suffix "ci-1234"

  • Affectez 2.1.0 à la version du package à l’aide de la propriété MSBuild PackageVersion :

    dotnet pack -p:PackageVersion=2.1.0

  • Empaquetez le projet pour un framework cible spécifique :

    dotnet pack -p:TargetFrameworks=net45

  • Packez le projet et utilisez un runtime spécifique (Windows) pour l’opération de restauration :

    dotnet pack --runtime win-x64

  • Empaquetez le projet à l’aide d’un fichier .nuspec :

    dotnet pack ~/projects/app1/project.csproj -p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget

    Pour plus d’informations sur l’utilisation de NuspecFile, NuspecBasePath et NuspecProperties, consultez les ressources suivantes :