Partager via

dotnet Pack

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

Nom

dotnet pack - Packe le code dans un package NuGet.

Synopsis

dotnet pack [<PROJECT>|<SOLUTION>]
  [--artifacts-path <ARTIFACTS_DIR>] [-c|--configuration <CONFIGURATION>]
  [--disable-build-servers] [--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

Descriptif

La dotnet pack commande génère le projet et crée des packages NuGet. Le résultat de cette commande est un package NuGet (autrement dit, un fichier .nupkg ).

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

  • --include-symbols - il crée le package de symboles.
  • --include-source - il crée le package de symboles avec un src dossier dans lequel se trouvent les fichiers sources.

Les dépendances NuGet du projet pack sont ajoutées au fichier .nuspec , de sorte qu’elles sont correctement résolues lorsque le package est installé. Si le projet packé a 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 de projet à projet.

Par défaut, dotnet pack génère d’abord le projet. Si vous souhaitez éviter ce comportement, passez l’option --no-build . Cette option est souvent utile dans les scénarios de génération d’intégration continue (CI) où vous savez que le code a été créé précédemment.

Note

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

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

Note

Les projets web ne sont pas packables.

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

Projet ou solution à packer. Il s’agit d’un chemin d’accès à un fichier csproj, vbproj ou fsproj, ou à un fichier ou répertoire de solution. Si elle n’est pas spécifiée, la commande recherche dans le répertoire actif un fichier projet ou solution.

Options

  • --artifacts-path <ARTIFACTS_DIR>

    Tous les fichiers de sortie de build de la commande exécutée vont dans les sous-dossiers sous le chemin spécifié, séparés par projet. Pour plus d’informations, consultez disposition de sortie d’artefacts. Disponible depuis le Kit de développement logiciel (SDK) .NET 8.

  • -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 configuration Release par défaut pour les projets dont TargetFramework est défini sur net8.0 ou une version ultérieure. La configuration de build par défaut est Debug pour 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.

  • --disable-build-servers

    Force la commande à ignorer tous les serveurs de build persistants. Cette option offre un moyen cohérent de désactiver toute utilisation de la mise en cache de build, ce qui force une build à partir de zéro. Une build qui ne repose pas sur des caches est utile quand les caches peuvent être endommagés ou incorrects pour une raison quelconque. Disponible depuis le SDK .NET 7.

  • --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.

  • --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 src dossier du 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.

  • --no-build

    Ne génère pas le projet avant l’empaquetage. L’indicateur --no-restore est également défini implicitement.

  • --no-dependencies

    Ignore les références de projet à projet 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 ou le message de copyright.

  • -o|--output <OUTPUT_DIRECTORY>

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

    • Sdk .NET 7.0.200

      Dans le Kit de développement logiciel (SDK) 7.0.200, si vous spécifiez l’option lors de l’exécution --output de cette commande sur une solution, l’interface CLI émet une erreur. Il s’agit d’une régression et a été corrigée dans la version 7.0.201 et ultérieure du Kit de développement logiciel (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 serviceable dans le package. Pour plus d’informations, consultez le blog .NET : .NET Framework 4.5.1 prend en charge les mises à jour de sécurité Microsoft pour les bibliothèques NuGet .NET.

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

    Spécifie si Terminal Logger 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.

    Terminal Logger vous montre la phase de restauration suivie de 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 VersionSuffix propriété MSBuild. L’effet de cette propriété sur la version du package dépend des valeurs des Version propriétés et VersionPrefix des valeurs, comme indiqué dans le tableau suivant :

    Propriétés avec des valeurs Version du package
    Aucun 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 c’est 0.1.2 et si vous passez --version-suffix rc.1 à dotnet pack, la version du package sera 0.1.2-rc.1.

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

  • -?|-h|--help

    Imprime une description de l’utilisation de la commande.

Examples

  • Packez le projet dans le répertoire actif :

    dotnet pack

  • Packez le app1 projet :

    dotnet pack ~/projects/app1/project.csproj

  • Packez le projet dans le répertoire actif et placez les packages résultants dans le nupkgs dossier :

    dotnet pack --output nupkgs

  • Packez le projet dans le répertoire actif dans le nupkgs dossier et ignorez 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 , packez le projet actuel et mettez à jour la version du package résultante avec le suffixe donné :

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

  • Définissez la version du package avec 2.1.0 la PackageVersion propriété MSBuild :

    dotnet pack -p:PackageVersion=2.1.0

  • Packez le projet pour une infrastructure 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

  • Packez 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 NuspecFile, NuspecBasePathet NuspecPropertiespour plus d’informations, consultez les ressources suivantes :

  • Last updated on