dotnet pack
Cet article s’applique à :✔️ SDK .NET Core 3.1 et versions ultérieures
dotnet pack
: Place le code dans un package NuGet.
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
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 unsrc
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.
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.
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.
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.
--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
Release
configuration par défaut pour les projets dont TargetFramework est défininet8.0
sur ou une version ultérieure. La configuration de build par défaut concerneDebug
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]
etdiag[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ésVersion
etVersionPrefix
, 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
uniquement1.0.0-$(VersionSuffix)
VersionPrefix
etVersionSuffix
$(VersionPrefix)-$(VersionSuffix)
Si vous souhaitez utiliser
--version-suffix
, spécifiezVersionPrefix
et nonVersion
dans le fichier projet. Par exemple, siVersionPrefix
est0.1.2
et que vous faites passer--version-suffix rc.1
àdotnet pack
, la version du package sera0.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.
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é MSBuildPackageVersion
: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
etNuspecProperties
, consultez les ressources suivantes :
Commentaires sur .NET
.NET est un projet open source. Sélectionnez un lien pour fournir des commentaires :