dotnet publish

  • Article

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

Nom

dotnet publish - Publie l’application et ses dépendances dans un dossier en vue d’un déploiement sur un système d’hébergement.

Synopsis

dotnet publish [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
    [-c|--configuration <CONFIGURATION>] [--disable-build-servers]
    [-f|--framework <FRAMEWORK>] [--force] [--interactive]
    [--manifest <PATH_TO_MANIFEST_FILE>] [--no-build] [--no-dependencies]
    [--no-restore] [--nologo] [-o|--output <OUTPUT_DIRECTORY>]
    [--os <OS>] [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--sc|--self-contained [true|false]] [--no-self-contained]
    [-s|--source <SOURCE>] [--tl:[auto|on|off]]
    [--use-current-runtime, --ucr [true|false]]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet publish -h|--help

Description

dotnet publish compile l’application, parcourt ses dépendances spécifiées dans le fichier projet et publie l’ensemble de fichiers obtenus dans un répertoire. La sortie inclut les ressources suivantes :

  • Le code de langage intermédiaire (IL) dans un assembly avec l’extension dll.
  • Un fichier .deps.json qui inclut toutes les dépendances du projet.
  • Un fichier .runtimeconfig.json qui spécifie le runtime partagé attendu par l’application, ainsi que d’autres options de configuration pour le runtime (par exemple, le type de garbage collection).
  • Les dépendances de l’application, qui sont copiées à partir du cache NuGet dans le dossier de sortie.

La sortie de la commande dotnet publish est prête pour le déploiement sur un système d’hébergement (par exemple, un serveur, PC, Mac, ordinateur portable) à des fins d’exécution. Il s’agit de la seule façon officiellement prise en charge pour préparer l’application au déploiement. Selon le type de déploiement spécifié par le projet, le système d’hébergement peut ou non avoir installé le runtime partagé .NET sur celui-ci. Pour plus d’informations, consultez Publier des applications .NET avec l’interface CLI .NET.

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.

MSBuild

La commande dotnet publish appelle MSBuild, qui appelle la cible de Publish. Si la propriété IsPublishable est définie false pour un projet particulier, la cible Publish ne peut pas être appelée et la commande dotnet publish exécute uniquement l dotnet restore implicite sur le projet.

Les paramètres passés à dotnet publish sont passés à MSBuild. Les paramètres -c et -o correspondent aux propriétés Configuration et PublishDir de MSBuild, respectivement.

La commande dotnet publish accepte les options MSBuild, telles que -p pour la définition des propriétés et -l pour définir un enregistreur d’événements. Par exemple, vous pouvez définir une propriété MSBuild à l’aide du format suivant : -p:<NAME>=<VALUE>.

Fichiers .pubxml

Vous pouvez également définir des propriétés liées à la publication en faisant référence à un fichier .pubxml. Par exemple :

dotnet publish -p:PublishProfile=FolderProfile

L’exemple précédent utilise le fichier FolderProfile.pubxml qui se trouve dans le dossier <project_folder/>Properties/PublishProfiles. Si vous spécifiez un chemin d’accès et une extension de fichier lors de la définition de la propriété PublishProfile, ils sont ignorés. MSBuild par défaut recherche dans le dossier Properties/PublishProfiles et suppose l’extension de fichier pubxml. Pour spécifier le chemin d’accès et le nom de fichier, y compris l’extension, définissez la propriété PublishProfileFullPath au lieu de la propriété PublishProfile.

Dans le fichier .pubxml :

  • PublishUrl est utilisé par Visual Studio pour désigner la cible de publication.
  • PublishDir est utilisé par l’interface CLI pour désigner la cible de publication.

Si vous souhaitez que le scénario fonctionne à tous les endroits, vous pouvez initialiser ces deux propriétés sur la même valeur dans le fichier .pubxml. Lorsque le problème GitHub dotnet/sdk#20931 est résolu, une seule de ces propriétés doit être définie.

Certaines propriétés du fichier .pubxml sont respectées uniquement par Visual Studio et n’ont aucun effet sur dotnet publish. Nous nous efforçons d'aligner l’interface CLI sur le comportement de Visual Studio. Mais certaines propriétés ne seront jamais utilisées par l’interface CLI. L’interface CLI et Visual Studio gèrent la partie empaquetage de la publication, et dotnet/sdk#29817 prévoit d’ajouter la prise en charge d’autres propriétés associées à cette étape. Mais l'interface CLI ne prend pas en charge la partie automatisation du déploiement de la publication, et les propriétés associées ne sont pas prises en charge. Voici les propriétés .pubxml les plus notables qui ne sont pas prises en charge par dotnet publish et qui ont un impact sur la génération :

  • LastUsedBuildConfiguration
  • Configuration
  • Platform
  • LastUsedPlatform
  • TargetFramework
  • TargetFrameworks
  • RuntimeIdentifier
  • RuntimeIdentifiers

MSBuild (propriétés)

Les propriétés MSBuild suivantes modifient la sortie de dotnet publish.

  • PublishReadyToRun

    Compile les assemblys d’application au format ReadyToRun (R2R). R2R est une forme de compilation ahead-of-time (AOT). Pour plus d’informations, consultez Images ReadyToRun.

    Pour afficher des avertissements sur les dépendances manquantes susceptibles d’entraîner des échecs d’exécution, utilisez PublishReadyToRunShowWarnings=true.

    Nous vous recommandons de spécifier PublishReadyToRun dans un profil de publication plutôt que sur la ligne de commande.

  • PublishSingleFile

    Empaquette l’application dans un exécutable à fichier unique spécifique à la plateforme. Pour plus d’informations sur la publication monofichier, consultez le document conceptuel sur l’outil de regroupement monofichier.

    Nous vous recommandons de spécifier cette option dans le fichier projet plutôt que sur la ligne de commande.

  • PublishTrimmed

    Supprime les bibliothèques inutilisées pour réduire la taille de déploiement d’une application lors de la publication d’un exécutable autonome. Pour plus d’informations, consultez Découper les déploiements autonomes et les exécutables. Disponible depuis le Kit de développement logiciel (SDK) .NET 6.

    Nous vous recommandons de spécifier cette option dans le fichier projet plutôt que sur la ligne de commande.

Pour plus d’informations, consultez les ressources suivantes :

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 à publier.

    • PROJECT est le chemin et nom de fichier d’un fichier projet C#, F# ou Visual Basic, ou le chemin vers un répertoire qui contient un fichier projet C#, F# ou Visual Basic. Si le répertoire n’est pas spécifié, il est défini par défaut sur le répertoire actif.

    • SOLUTION est le chemin d’accès et le nom de fichier d’un fichier solution (extension .sln) ou le chemin d’accès à un répertoire qui contient un fichier solution. Si le répertoire n’est pas spécifié, il est défini par défaut sur le répertoire actif.

Options

  • -a|--arch <ARCHITECTURE>

    Spécifie l’architecture cible. Il s’agit d’une syntaxe abrégée pour définir l’identificateur d’exécution (RID), où la valeur fournie est combinée avec le RID par défaut. Par exemple, sur une machine win-x64, la spécification de --arch x86 définit le RID sur win-x86. Si vous utilisez cette option, n’utilisez pas l’option -r|--runtime. Disponible depuis .NET 6 Preview 7.

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

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

  • -f|--framework <FRAMEWORK>

    Publie l’application pour le framework cible spécifié. Le framework cible doit être spécifié dans le fichier projet.

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

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

  • --manifest <PATH_TO_MANIFEST_FILE>

    Spécifie un ou plusieurs manifestes cibles à utiliser pour épurer l’ensemble des packages publiés avec l’application. Le fichier manifeste fait partie de la sortie de la commande dotnet store. Pour spécifier plusieurs manifestes, ajoutez une option --manifest pour chaque manifeste.

  • --no-build

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

  • --no-dependencies

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

  • --nologo

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

  • --no-restore

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

  • -o|--output <OUTPUT_DIRECTORY>

    Spécifie le chemin d’accès du répertoire de sortie.

    S’il n’est pas spécifié, il est défini par défaut sur [project_file_folder]/bin/[configuration]/[framework]/publish/ pour un exécutable dépendant du framework et des fichiers binaires multiplateformes. Par défaut [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ pour un exécutable autonome.

    Dans un projet web, si le dossier de sortie se trouve dans le dossier du projet, les commandes dotnet publish successives entraînent des dossiers de sortie imbriqués. Par exemple, si le dossier du projet est myproject et que le dossier de sortie de publication est myproject/publish, et que vous exécutez dotnet publish deux fois, la deuxième exécution place les fichiers de contenu tels que les fichiers .config et .json dans myproject/publish/publish. Pour éviter l’imbrication des dossiers de publication, spécifiez un dossier de publication qui n’est pas directement sous le dossier du projet ou excluez le dossier de publication du projet. Pour exclure un dossier de publication nommé publishoutput, ajoutez l’élément suivant à un élément PropertyGroup dans le fichier .csproj :

    <DefaultItemExcludes>$(DefaultItemExcludes);publishoutput**</DefaultItemExcludes>

    • Kit SDK .NET 7.0.200 et versions ultérieures

      Si vous spécifiez l’option --output lors de l’exécution de cette commande sur une solution, l’interface CLI émet un avertissement (une erreur dans la version 7.0.200) en raison du manque de clarté de la sémantique du chemin de sortie. L’option --output n’est pas autorisée, car toutes les sorties de tous les projets générés seraient copiées dans le répertoire spécifié. Or, cette configuration n’est compatible ni avec les projets à plusieurs cibles, ni avec les projets présentant différentes versions de dépendances directes et transitives. Pour plus d’informations, consultez Option --output au niveau de la solution non valide pour les commandes liées à la build.

    • Kit de développement logiciel (SDK) .NET Core 3.x et versions ultérieures

      Si vous spécifiez un chemin relatif lors de la publication d’un projet, le répertoire de sortie généré est relatif au répertoire de travail actuel, et non à l’emplacement du fichier projet.

      Si vous spécifiez un chemin relatif lors de la publication d’une solution, toutes les sorties de tous les projets sont envoyées dans le dossier spécifié par rapport au répertoire de travail actuel. Pour que la sortie de la publication aille dans des dossiers séparés pour chaque projet, spécifiez un chemin relatif en utilisant la propriété PublishDir msbuild au lieu de l'option --output. Par exemple, dotnet publish -p:PublishDir=.\publish envoie une sortie de publication pour chaque projet à un dossier publish sous le dossier qui contient le fichier projet.

    • Kit de développement logiciel (SDK) .NET Core 2.x

      Si vous spécifiez un chemin relatif lors de la publication d’un projet, le répertoire de sortie généré est relatif à l’emplacement du fichier projet, et non au répertoire de travail actuel.

      Si vous spécifiez un chemin relatif lors de la publication d’une solution, la sortie de chaque projet se trouve dans un dossier distinct par rapport à l’emplacement du fichier projet. Si vous spécifiez un chemin absolu lors de la publication d’une solution, toutes les sorties de publication pour tous les projets sont envoyées dans le dossier spécifié.

  • --os <OS>

    Spécifie le système d’exploitation cible. Il s’agit d’une syntaxe abrégée pour définir l’identificateur d’exécution (RID), où la valeur fournie est combinée avec le RID par défaut. Par exemple, sur une machine win-x64, la spécification de --os linux définit le RID sur linux-x64. Si vous utilisez cette option, n’utilisez pas l’option -r|--runtime. Disponible depuis .NET 6.

  • --sc|--self-contained [true|false]

    Publie le runtime .NET avec votre application ; ainsi, vous n’avez pas besoin d’installer le runtime sur l’ordinateur cible. La valeur par défaut est true si un identificateur d’exécution est spécifié et que le projet est un projet exécutable (et non un projet de bibliothèque). Pour plus d’informations, consultez la publication d’applications .NET et la publication d’applications .NET avec l’interface CLI .NET.

    Si cette option est utilisée sans spécifier true ou false, la valeur par défaut est true. Dans ce cas, ne placez pas la solution ou l’argument de projet immédiatement après --self-contained, car true ou false est attendu dans cette position.

  • --no-self-contained

    Équivaut à --self-contained false.

  • --source <SOURCE>

    URI de la source du package NuGet à utiliser pendant l’opération de restauration.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Publie l’application pour un runtime donné. Pour connaître les identificateurs de runtime, consultez le catalogue des identificateurs de runtime. Pour plus d’informations, consultez la publication d’applications .NET et la publication d’applications .NET avec l’interface CLI .NET. Si vous utilisez cette option, utilisez --self-contained ou --no-self-contained également.

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

  • --use-current-runtime, --ucr [true|false]

    Définit RuntimeIdentifier sur un RuntimeIdentifier portable sur plateforme basée sur l’un de vos ordinateurs. Cela se produit implicitement avec les propriétés qui nécessitent un RuntimeIdentifier, comme SelfContained, PublishAot, PublishSelfContained, PublishSingleFile et PublishReadyToRun. Si la propriété a la valeur false, cette résolution implicite ne se produit plus.

  • -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]. La valeur par défaut est minimal. Pour plus d'informations, consultez LoggerVerbosity.

  • --version-suffix <VERSION_SUFFIX>

    Définit le suffixe de version qui remplace l’astérisque (*) dans le champ de version du fichier projet.

Exemples

  • Créez un binaire multiplateforme dépendant du framework pour le projet dans le répertoire actif :

    dotnet publish

    À compter du Kit de développement logiciel (SDK) .NET Core 3.0, cet exemple crée également un exécutable dépendant du framework pour la plateforme actuelle.

  • Créez un exécutable autonome pour le projet dans le répertoire actif, pour un runtime spécifique :

    dotnet publish --runtime osx-x64

    Le RID doit se trouver dans le fichier projet.

  • Créez un exécutable dépendant du framework pour le projet dans le répertoire actif, pour une plateforme spécifique :

    dotnet publish --runtime osx-x64 --self-contained false

    Le RID doit se trouver dans le fichier projet. Cet exemple s’applique au SDK .NET Core 3.0 et versions ultérieures.

  • Publiez le projet dans le répertoire actif, pour un runtime et une infrastructure cible spécifiques :

    dotnet publish --framework net8.0 --runtime osx-x64

  • Publiez le fichier projet spécifié :

    dotnet publish ~/projects/app1/app1.csproj

  • Publiez l’application actuelle, mais ne restaurez pas les références projet-à-projet (P2P), juste le projet racine pendant l’opération de restauration :

    dotnet publish --no-dependencies

Voir aussi