Partager via

dotnet publish

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

Nom

dotnet publish : publie l’application et ses dépendances dans un dossier pour le déploiement sur un système d’hébergement.

Synopsis

dotnet publish [<PROJECT>|<SOLUTION>|<FILE>] [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-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>] [-p|--property:<PROPERTYNAME>=<VALUE>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--sc|--self-contained] [--no-self-contained]
    [-s|--source <SOURCE>] [--tl:[auto|on|off]]
    [--ucr|--use-current-runtime]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet publish -h|--help

Description

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

  • Code de langage intermédiaire (IL) dans un assembly avec une extension dll .
  • Fichier .deps.json qui inclut toutes les dépendances du projet.
  • 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, 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 vers un système d’hébergement (par exemple, un serveur, un PC, Mac, un ordinateur portable) pour l’exécution. Il s’agit du seul moyen officiellement pris en charge de préparer l’application pour le 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 la vue d’ensemble de la publication d’applications .NET.

Restauration implicite

Vous n’avez pas besoin d’exécuter dotnet restore, car elle est exécutée implicitement par toutes les commandes qui nécessitent une restauration, comme dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishet 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 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 de la restauration.

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 Publish. Si la propriété IsPublishable est définie sur false pour un projet particulier, la cible Publish ne peut pas être appelée et la commande dotnet publish exécute uniquement la de restauration dotnet implicite sur le projet.

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

La commande dotnet publish accepte les options MSBuild, telles que -p pour définir des propriétés et -l pour définir un enregistreur d’événements. Par exemple, vous pouvez définir une propriété MSBuild au format : -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, elles sont ignorées. MSBuild par défaut recherche dans le dossier Properties/PublishProfiles et suppose que 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 à 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 travaillons à l’alignement de l’interface CLI avec 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 effectuent tous les deux l’aspect de la publication et dotnet/sdk#29817 prévoit d’ajouter la prise en charge d’autres propriétés associées. Toutefois, l’interface CLI ne prend pas en charge l’aspect d’automatisation du déploiement de la publication et les propriétés associées à celles-ci. Les propriétés .pubxml les plus notables qui ne sont pas prises en charge par dotnet publish sont les suivantes qui affectent la build :

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

Propriétés MSBuild

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 anticipée (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 à fichier unique, consultez le document de conception bundler à fichier unique. Lorsque cette propriété est définie truesur , la PublishSelfContained propriété est implicitement définie sur true.

    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échargements du manifeste de charge de travail

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

Arguments

PROJECT | SOLUTION | FILE

Fichier projet ou solution ou C# (application basée sur des fichiers) sur lequel fonctionner. Si aucun fichier n’est spécifié, MSBuild recherche dans le répertoire actif un projet ou une solution.

  • PROJECT est le chemin d’accès et le nom de fichier d’un fichier projet C#, F# ou Visual Basic, ou le chemin d’un répertoire qui contient un fichier projet C#, F# ou Visual Basic.

  • SOLUTION est le chemin d’accès et le nom de fichier d’un fichier solution (.sln ou extension .slnx), ou le chemin d’accès à un répertoire qui contient un fichier solution.

  • FILE est un argument ajouté dans .NET 10. Chemin d’accès et nom de fichier d’une application basée sur un fichier. Les applications basées sur des fichiers sont contenues dans un fichier unique généré et exécuté sans fichier de projet (.csproj) correspondant. Pour plus d’informations, consultez Générer des applications C# basées sur des fichiers.

Options

  • -a|--arch <ARCHITECTURE>

    Spécifie l’architecture cible. Il s’agit d’une syntaxe abrégée permettant de définir l'RID (Runtime Identifier) , où la valeur fournie est combinée avec le RID par défaut. Par exemple, sur un ordinateur win-x64, en spécifiant --arch x86 définissez le RID sur win-x86. Si vous utilisez cette option, n’utilisez pas l’option -r|--runtime. Disponible depuis .NET 6 Preview 7.

  • --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 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 s’appuie pas sur les caches est utile lorsque les caches peuvent être endommagés ou incorrects pour une raison quelconque. Disponible depuis le Kit de développement logiciel (SDK) .NET 7.

  • -f|--framework <FRAMEWORK>

    Publie l’application pour l’infrastructure cible spécifiée. Vous devez spécifier l’infrastructure cible dans le fichier projet.

  • --force

    Force la résolution de toutes les dépendances même si la dernière restauration a réussi. La spécification de cet indicateur est identique à la suppression du fichier project.assets.json.

  • --interactive

    Permet à la commande d’arrêter et d’attendre l’entrée ou l’action de l’utilisateur. Par exemple, pour terminer l’authentification.

  • --manifest <PATH_TO_MANIFEST_FILE>

    Spécifie un ou plusieurs manifestes cibles à utiliser pour découper l’ensemble de 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. Il définit également implicitement l’indicateur de --no-restore.

  • --no-dependencies

    Ignore les références de projet à projet et restaure uniquement le projet racine.

  • --nologo

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

  • --no-restore

    N’exécute pas de restauration implicite lors de 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 par défaut [project_file_folder]/bin/[configuration]/[framework]/publish/ pour un exécutable dépendant du framework et des fichiers binaires multiplateformes. Il est 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 de dotnet publish successives entraînent des dossiers de sortie imbriqués. Par exemple, si le dossier du projet est mon projet, 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 des fichiers de contenu tels que .config et .json fichiers 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>

    • 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 de la sémantique peu claire du chemin de sortie. L’option --output n’est pas autorisée, car toutes les sorties de tous les projets générés sont copiées dans le répertoire spécifié, ce qui n’est pas compatible avec les projets multi-ciblés, ainsi que les projets qui ont différentes versions de dépendances directes et transitives. Pour plus d’informations, consultez 'option de --output au niveau de la solution n’est plus valide pour les commandes liées à la génération.

    • 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 rendre la sortie de publication atteindre des dossiers distincts pour chaque projet, spécifiez un chemin relatif à l’aide de la propriété msbuild PublishDir au lieu de l’option --output. Par exemple, dotnet publish -p:PublishDir=.\publish envoie une sortie de publication pour chaque projet dans un dossier publish sous le dossier qui contient le fichier projet.

  • --os <OS>

    Spécifie le système d’exploitation cible. Il s’agit d’une syntaxe abrégée permettant de définir l'RID (Runtime Identifier) , où la valeur fournie est combinée avec le RID par défaut. Par exemple, sur un ordinateur win-x64, en spécifiant --os linux définissez le RID sur linux-x64. Si vous utilisez cette option, n’utilisez pas l’option -r|--runtime. Disponible depuis .NET 6.

  • --sc|--self-contained

    Publiez le runtime .NET avec votre application afin que le runtime n’ait pas besoin d’être installé sur l’ordinateur cible.

  • -p|--property:<PROPERTYNAME>=<VALUE>

    Définit une ou plusieurs propriétés MSBuild. Spécifiez plusieurs propriétés délimitées par des points-virgules ou en répétant l’option :

    --property:<NAME1>=<VALUE1>;<NAME2>=<VALUE2>
--property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>

  • --no-self-contained

    Publiez votre application en tant qu’application dépendante de l’infrastructure. Un runtime .NET compatible doit être installé sur l’ordinateur cible pour exécuter votre application.

  • --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 obtenir la liste des identificateurs d’exécution (RID), consultez le catalogue RID . Pour plus d’informations, consultez la vue d’ensemble de la publication d’applications .NET. Si vous utilisez cette option, utilisez --self-contained ou --no-self-contained également.

  • --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 des terminaux. 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 de 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 des terminaux. 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 création apparaissent en bas du terminal. Chaque projet généré 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 build. Lorsqu’un projet est terminé, une seule section « build terminée » est écrite qui capture :

    • Nom du projet généré.
    • Framework cible (s’il est multi-ciblé).
    • État de cette build.
    • Sortie principale de cette build (qui est en lien hypertexte).
    • Tous les diagnostics générés pour ce projet.

    Cette option est disponible à partir de .NET 8.

  • --ucr|--use-current-runtime

    Utilisez le runtime actuel comme runtime cible.

  • -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 pour remplacer l’astérisque (*) dans le champ de version du fichier projet.

  • -?|-h|--help

    Imprime une description de l’utilisation de la commande.

Exemples

  • Créez un binaire multiplat eforme dépendant de l’infrastructure pour le projet dans le répertoire actif :

    dotnet publish

    À compter du 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 de l’infrastructure 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

  • Publiez le programme C# basé sur des fichiers app.cs dans le répertoire actif :

    dotnet publish app.cs

    La prise en charge du programme basé sur les fichiers a été ajoutée dans le Kit de développement logiciel (SDK) .NET 10.0.100.

Voir aussi

  • Last updated on