Partager via

Vue d’ensemble de la publication d’applications .NET

Cet article explique les différentes façons de publier une application .NET. Il couvre les modes de publication, la façon de produire des exécutables et des fichiers binaires multiplateformes, ainsi que l’impact de chaque approche sur les environnements de déploiement et d’exécution. Vous pouvez publier des applications .NET à l’aide de l’interface CLI .NET ou de Visual Studio.

Pour obtenir un bref didacticiel sur la publication, consultez Tutoriel : Publier une application console .NET à l’aide de Visual Studio Code.

Pour obtenir un bref didacticiel sur la publication, consultez Tutoriel : Publier une application console .NET à l’aide de Visual Studio.

Qu’est-ce que la publication

La publication d’une application .NET signifie compiler le code source pour créer un fichier exécutable ou binaire, ainsi que ses dépendances et ses fichiers associés, pour la distribution. Après la publication, vous déployez l’application sur un serveur, une plateforme de distribution, un conteneur ou un environnement cloud. Le processus de publication prépare une application pour le déploiement et l’utilisation en dehors d’un environnement de développement.

Modes de publication

Il existe deux méthodes principales pour publier une application. Certains facteurs qui influencent cette décision incluent si l’environnement de déploiement a installé le runtime .NET approprié et si vous avez besoin de fonctionnalités de compilation spécifiques qui nécessitent un regroupement du runtime avec votre application. Les deux modes de publication sont les suivants :

  • Publier autonome
    Ce mode produit un dossier de publication qui inclut un exécutable spécifique à la plateforme utilisé pour démarrer l’application, un fichier binaire compilé contenant du code d’application, toutes les dépendances d’application et le runtime .NET requis pour exécuter l’application. L’environnement qui exécute l’application n’a pas besoin d’avoir préinstallé le runtime .NET.

  • Publier dépendant de l’infrastructure
    Ce mode produit un dossier de publication qui inclut un exécutable facultatif spécifique à la plateforme utilisé pour démarrer l’application, un fichier binaire compilé contenant du code d’application et toutes les dépendances d’application. L’environnement qui exécute l’application doit avoir une version du runtime .NET installée que l’application peut utiliser.

Important

Vous spécifiez la plateforme cible avec un identificateur d’exécution (RID). Pour plus d’informations sur les RID, consultez le catalogue RID .NET.

Principes de base de la publication

Le <TargetFramework> paramètre du fichier projet spécifie l’infrastructure cible par défaut lorsque vous publiez votre application. Vous pouvez modifier l’infrastructure cible en n’importe quel moniker (TFM) du framework cible valide. Par exemple, si votre projet utilise <TargetFramework>net9.0</TargetFramework>, un fichier binaire qui cible .NET 9 est créé.

Si vous souhaitez cibler plusieurs frameworks, vous pouvez définir le <TargetFrameworks> paramètre sur plusieurs valeurs TFM, séparées par un point-virgule. Lorsque vous générez votre application, votre application est générée pour chaque infrastructure cible définie par votre projet. Toutefois, lorsque vous publiez votre application, vous devez spécifier l’infrastructure cible :

Le mode de configuration de build par défaut est Release, sauf si modifié avec le -c paramètre.

dotnet publish -c Release -f net9.0

Le répertoire de sortie par défaut de la dotnet publish commande est ./bin/<BUILD-CONFIGURATION>/<TFM>/publish/. Par exemple, dotnet publish -c Release -f net9.0 publie sur ./bin/Release/net9.0/publish/. Toutefois, vous pouvez opter pour un chemin de sortie simplifié et une structure de dossiers pour toutes les sorties de build. Pour plus d’informations, consultez la disposition de sortie Artifacts.

Dans Visual Studio, créez des profils de publication distincts pour chaque infrastructure cible.

Binaires portables

Lorsque vous publiez une application .NET, vous pouvez cibler une plateforme spécifique ou créer un fichier binaire portable. Par défaut, même lors de la création d’un binaire portable, .NET publie un exécutable spécifique à la plateforme (« apphost ») en même temps que la DLL portable, sauf si vous désactivez explicitement ce comportement.

L’exécutable spécifique à la plateforme est créé en raison de la UseAppHost propriété, qui est par défaut true. Pour publier uniquement la DLL portable sans exécutable spécifique à la plateforme, définissez-la UseAppHostfalse sur la ligne de commande (-p:UseAppHost=false) ou en tant que propriété de projet.

L’avantage de cibler une plateforme spécifique est qu’elle peut gérer les dépendances natives dont votre application peut avoir besoin, garantissant ainsi la compatibilité avec les exigences spécifiques de la plateforme cible.

Dépendances natives

Si votre application a des dépendances natives, elle peut ne pas s’exécuter sur un autre système d’exploitation s’il est publié en tant que binaire portable. Par exemple, les applications qui dépendent de l’API Windows ne s’exécutent pas en mode natif sur macOS ou Linux. Vous devez fournir du code spécifique à la plateforme et compiler un exécutable pour chaque plateforme.

Envisagez également, si une bibliothèque que vous avez référencée fournit des dépendances spécifiques à la plateforme, votre application peut ne pas s’exécuter sur chaque plateforme. Toutefois, lorsque vous publiez et ciblez une plateforme spécifique, les dépendances spécifiques à la plateforme d’un package NuGet sont copiées dans le dossier de publication.

Pour vous assurer que votre application est publiée avec ses dépendances natives, publiez pour une plateforme spécifique :

dotnet publish -c Release -r <RID>

  • -c Release

    Ce commutateur définit la configuration de build sur Release, qui est optimisée pour le déploiement de production.

  • -r <RID>

    Ce commutateur utilise un identificateur d’exécution (RID) pour spécifier la plateforme cible et garantit que les dépendances natives sont incluses (si nécessaire). Pour obtenir la liste des identificateurs d’exécution, consultez le catalogue RID (Runtime Identifier).

  1. Cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions , puis sélectionnez Publier.
  2. S’il s’agit de votre première publication, sélectionnez Dossier comme cible de publication, puis sélectionnez Suivant.
  3. Choisissez un emplacement de dossier ou acceptez la valeur par défaut, puis sélectionnez Terminer.
  4. Dans le profil de publication, sélectionnez Afficher tous les paramètres.
  5. Définissez le runtime cible sur votre plateforme souhaitée (par exemple, win-x64 pour Windows 64 bits).
  6. Sélectionnez Enregistrer , puis Publier.

Pour obtenir la liste des identificateurs d’exécution, consultez le catalogue RID (Runtime Identifier).

Référence rapide

Le tableau suivant fournit des exemples rapides de publication de votre application.

Mode de publication Commande
Déploiement dépendant de l’infrastructure dotnet publish -c Release [-r <RID>]
Déploiement dépendant de l’infrastructure (DLL) dotnet publish -c Release -p:UseAppHost=false
Déploiement autonome dotnet publish -c Release [-r <RID>] --self-contained true
Déploiement à fichier unique dotnet publish -c Release [-r <RID>] -p:PublishSingleFile=true
Déploiement AOT natif dotnet publish -c Release [-r <RID>] -p:PublishAot=true
Déploiement ReadyToRun dotnet publish -c Release [-r <RID>] -p:PublishReadyToRun=true
Déploiement de conteneurs dotnet publish -c Release [-r <RID>] -t:PublishContainer

Déploiement dépendant de l’infrastructure

Le déploiement dépendant de l’infrastructure est le mode par défaut lorsque vous publiez à partir de l’interface CLI ou de Visual Studio. Dans ce mode, un exécutable spécifique à la plateforme est créé qui peut être utilisé pour démarrer votre application. L’exécutable spécifique à la plateforme est nommé quelque chose de similaire à myapp.exe sur Windows ou uniquement myapp sur d’autres plateformes.

Votre application est configurée pour cibler une version spécifique de .NET. Ce runtime .NET ciblé doit se trouver sur l’environnement dans lequel votre application s’exécute. Par exemple, si votre application cible .NET 9, tout environnement sur lequel votre application s’exécute doit avoir installé le runtime .NET 9.

La publication d’un déploiement dépendant du framework crée une application qui est automatiquement transférée vers le dernier correctif de sécurité .NET disponible sur l’environnement qui exécute l’application. Pour plus d’informations sur la liaison de version au moment de la compilation, consultez Sélectionner la version .NET à utiliser.

Avantages

  • Petit déploiement : seule l’application et ses dépendances sont distribuées. L’environnement dans lequel l’application est exécutée doit déjà avoir installé le runtime .NET.
  • Multiplateforme : l’application et tout . La bibliothèque basée sur NET s’exécute sur d’autres systèmes d’exploitation.
  • Utilise le dernier runtime corrigé : l’application utilise le dernier runtime installé dans l’environnement.

Inconvénients

  • Nécessite la préinstallation du runtime : l’application peut s’exécuter uniquement si la version de .NET cible est déjà installée dans l’environnement.
  • .NET peut changer : l’environnement dans lequel l’application est exécutée peut utiliser un runtime .NET plus récent, ce qui peut modifier le comportement de l’application.

Lancer des applications dépendantes de l’infrastructure

Il existe deux façons d’exécuter des applications dépendantes du framework : via l’exécutable spécifique à la plateforme (« apphost ») et via dotnet myapp.dll. Vous pouvez exécuter l’exécutable apphost directement au lieu d’appeler dotnet myapp.dll, ce qui est toujours un moyen acceptable d’exécuter l’application. Dans la mesure du possible, il est recommandé d’utiliser l’apphost. Il existe un certain nombre d’avantages à l’utilisation de l’apphost :

  • Les exécutables apparaissent comme des exécutables de plateforme native standard.
  • Les noms exécutables sont conservés dans les noms de processus, ce qui signifie que les applications peuvent être facilement reconnues en fonction de leurs noms.
  • Étant donné que l’apphost est un fichier binaire natif, des ressources natives telles que des manifestes peuvent être attachées.
  • Apphost dispose d’atténuations de sécurité de bas niveau disponibles appliquées par défaut, ce qui le rend plus sécurisé. Par exemple, la pile d’ombre de Control-flow Enforcement Technology (CET) est activée par défaut à partir de .NET 9. Les atténuations appliquées à dotnet sont le dénominateur commun minimal de tous les runtimes pris en charge.

Publier

dotnet publish -c Release [-r <RID>]

  • -c Release

    Ce commutateur définit la configuration de build sur Release, qui est optimisée pour le déploiement de production.

  • -r <RID>

    Ce commutateur utilise un identificateur d’exécution (RID) pour spécifier la plateforme cible et garantit que les dépendances natives sont incluses (si nécessaire). Pour obtenir la liste des identificateurs d’exécution, consultez le catalogue RID (Runtime Identifier).

Ou explicitement :

dotnet publish -c Release [-r <RID>] --self-contained false

  • --self-contained false

    Ce commutateur indique explicitement au Kit de développement logiciel (SDK) .NET de créer un déploiement dépendant du framework.

  1. Cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions , puis sélectionnez Publier.
  2. S’il s’agit de votre première publication, sélectionnez Dossier comme cible de publication, puis sélectionnez Suivant.
  3. Choisissez un emplacement de dossier ou acceptez la valeur par défaut, puis sélectionnez Terminer.
  4. Dans le profil de publication, sélectionnez Afficher tous les paramètres.
  5. Définissez le mode de déploiementsur dépendant de l’infrastructure (il s’agit de la valeur par défaut).
  6. Définissez le runtime cible sur votre plateforme souhaitée (par exemple, win-x64 pour Windows 64 bits).
  7. Sélectionnez Enregistrer , puis Publier.

Configurer le comportement de recherche d’installation de .NET

Par défaut, apphost découvre et utilise un runtime .NET installé globalement, avec des emplacements d’installation variables par plateforme. Pour plus d’informations sur la découverte des runtimes et leurs emplacements d’installation, consultez Résoudre les problèmes de lancement d’application.

Le chemin d’accès au runtime .NET peut également être personnalisé par exécution. La DOTNET_ROOT variable d’environnement peut être utilisée pour pointer vers l’emplacement personnalisé. Pour plus d’informations sur toutes les DOTNET_ROOT options de configuration, consultez les variables d’environnement .NET.

En général, la meilleure pratique pour l’utilisation DOTNET_ROOT consiste à :

  1. Effacez DOTNET_ROOT d’abord les variables d’environnement, ce qui signifie que toutes les variables d’environnement commencent par le texte DOTNET_ROOT.
  2. Définissez DOTNET_ROOT, et uniquement DOTNET_ROOT, sur le chemin cible.
  3. Exécutez l’apphost cible.

Dans .NET 9 et versions ultérieures, vous pouvez configurer les chemins de recherche d’installation .NET de l’exécutable publié via les propriétés et AppHostDotNetSearch les AppHostRelativeDotNet propriétés.

AppHostDotNetSearch permet de spécifier un ou plusieurs emplacements où l’exécutable recherche une installation .NET :

  • AppLocal: dossier de l’exécutable de l’application
  • AppRelative: chemin relatif à l’exécutable de l’application
  • EnvironmentVariable: valeur des variables d’environnement DOTNET_ROOT[_<arch>]
  • Global: emplacements d’installation globaux inscrits et par défaut

AppHostRelativeDotNet spécifie le chemin d’accès relatif à l’exécutable qui sera recherché lorsque AppHostDotNetSearch contient AppRelative.

Pour plus d’informations, consultez AppHostDotNetSearch, AppHostRelativeDotNetet installez les options d’emplacement dans apphost.

Déploiement dll multiplateforme

Vous pouvez également publier votre application en tant que DLL multiplateforme sans exécutable spécifique à la plateforme. Dans ce mode, un myapp.dll fichier est créé dans le dossier de sortie de publication. Pour exécuter votre application, accédez au dossier de sortie et utilisez la dotnet myapp.dll commande.

Pour publier en tant que DLL multiplateforme :

dotnet publish -c Release -p:UseAppHost=false

  • -c Release

    Ce commutateur définit la configuration de build sur Release, qui est optimisée pour le déploiement de production.

  • -p:UseAppHost=false

    Cette propriété désactive la création d’un exécutable spécifique à la plateforme, produisant uniquement la DLL portable.

  1. Cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions , puis sélectionnez Publier.
  2. S’il s’agit de votre première publication, sélectionnez Dossier comme cible de publication, puis sélectionnez Suivant.
  3. Choisissez un emplacement de dossier ou acceptez la valeur par défaut, puis sélectionnez Terminer.
  4. Dans le profil de publication, sélectionnez Afficher tous les paramètres.
  5. Définissez le mode de déploiementsur dépendant de l’infrastructure.
  6. Décochez Générer un fichier unique.
  7. Définissez le runtime cible sur Portable (ou laissez vide).
  8. Sélectionnez Enregistrer , puis Publier.

Déploiement autonome

Lorsque vous publiez un déploiement autonome (SCD), le processus de publication crée un exécutable spécifique à la plateforme. La publication d’un SCD inclut tous les fichiers .NET nécessaires pour exécuter votre application, mais elle n’inclut pas les dépendances natives de .NET. Ces dépendances doivent être présentes sur l’environnement avant l’exécution de l’application.

La publication d’un SCD crée une application qui ne passe pas à la dernière version du correctif de sécurité .NET disponible. Pour plus d’informations sur la liaison de version au moment de la compilation, consultez Sélectionner la version .NET à utiliser.

Avantages

  • Contrôler la version de .NET : contrôlez la version de .NET déployée avec l’application.
  • Ciblage spécifique à la plateforme : étant donné que l’application doit être publiée pour chaque plateforme, il est clair où l’application s’exécute.

Inconvénients

  • Déploiements plus volumineux : étant donné que l’application inclut le runtime .NET et toutes les dépendances, la taille de téléchargement et l’espace disque requis sont supérieurs à un déploiement dépendant du framework.
  • Plus difficile de mettre à jour la version .NET : le runtime .NET ne peut être mis à niveau qu’en publiant une nouvelle version de l’application.

Conseil

Vous pouvez réduire la taille totale des applications autonomes compatibles en publiant rogné ou en activant le mode invariant de la mondialisation. Pour plus d’informations sur le mode invariant de la globalisation, consultez le mode invariant de la globalisation .NET.

Publier

dotnet publish -c Release -r <RID> --self-contained true

  • -c Release

    Ce commutateur définit la configuration de build sur Release, qui est optimisée pour le déploiement de production.

  • -r <RID>

    Ce commutateur utilise un identificateur d’exécution (RID) pour spécifier la plateforme cible et garantit que les dépendances natives sont incluses (si nécessaire). Pour obtenir la liste des identificateurs d’exécution, consultez le catalogue RID (Runtime Identifier).

  • --self-contained true

    Ce commutateur indique au Kit de développement logiciel (SDK) .NET de créer un exécutable en tant que déploiement autonome (SCD).

  1. Cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions , puis sélectionnez Publier.
  2. S’il s’agit de votre première publication, sélectionnez Dossier comme cible de publication, puis sélectionnez Suivant.
  3. Choisissez un emplacement de dossier ou acceptez la valeur par défaut, puis sélectionnez Terminer.
  4. Dans le profil de publication, sélectionnez Afficher tous les paramètres.
  5. Définissez le mode de déploiementsur autonome.
  6. Définissez le runtime cible sur votre plateforme souhaitée (par exemple, win-x64 pour Windows 64 bits).
  7. Sélectionnez Enregistrer , puis Publier.

Déploiement à fichier unique

Lorsque vous publiez votre application en tant que déploiement à fichier unique, tous les fichiers dépendants de l’application sont regroupés dans un seul fichier binaire. Ce modèle de déploiement est disponible pour les applications dépendantes de l’infrastructure et autonomes, ce qui offre une option attrayante pour déployer et distribuer votre application en tant que fichier unique.

Les applications à fichier unique sont toujours spécifiques au système d’exploitation et à l’architecture. Vous devez publier pour chaque configuration, comme Linux x64, Linux Arm64, Windows x64, etc.

Avantages

  • Distribution simplifiée : Déployez et distribuez votre application en tant que fichier exécutable unique.
  • Encombrement réduit des fichiers : toutes les dépendances sont regroupées, ce qui élimine la nécessité de gérer plusieurs fichiers.
  • Déploiement facile : copiez un seul fichier pour déployer l’application.

Inconvénients

  • Taille de fichier supérieure : le fichier unique inclut toutes les dépendances, ce qui le rend plus grand que les fichiers individuels.
  • Démarrage plus lent : les fichiers doivent être extraits au moment de l’exécution, ce qui peut avoir un impact sur les performances de démarrage.
  • Spécifique à la plateforme : doit publier des fichiers distincts pour chaque plateforme cible.

Le déploiement à fichier unique peut être combiné avec d’autres optimisations telles que la suppression et la compilation ReadyToRun pour une optimisation supplémentaire.

Pour plus d’informations sur le déploiement à fichier unique, consultez Déploiement à fichier unique.

Publier

dotnet publish -c Release -r <RID> -p:PublishSingleFile=true

  • -c Release

    Ce commutateur définit la configuration de build sur Release, qui est optimisée pour le déploiement de production.

  • -r <RID>

    Ce commutateur utilise un identificateur d’exécution (RID) pour spécifier la plateforme cible et garantit que les dépendances natives sont incluses (si nécessaire). Pour obtenir la liste des identificateurs d’exécution, consultez le catalogue RID (Runtime Identifier).

  • -p:PublishSingleFile=true

    Cette propriété regroupe tous les fichiers dépendants de l’application en un seul binaire.

  1. Cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions , puis sélectionnez Publier.
  2. S’il s’agit de votre première publication, sélectionnez Dossier comme cible de publication, puis sélectionnez Suivant.
  3. Choisissez un emplacement de dossier ou acceptez la valeur par défaut, puis sélectionnez Terminer.
  4. Dans le profil de publication, sélectionnez Afficher tous les paramètres.
  5. Définissez le mode de déploiement sur autonome oudépendant de l’infrastructure.
  6. Définissez le runtime cible sur votre plateforme souhaitée (par exemple, win-x64 pour Windows 64 bits).
  7. Vérifiez produire un seul fichier.
  8. Sélectionnez Enregistrer , puis Publier.

Déploiement AOT natif

Le déploiement AOT natif compile votre application directement en code natif, ce qui élimine la nécessité d’un runtime. Cette option de publication utilise le mode de déploiement autonome , car le code natif compilé doit inclure tout ce qui est nécessaire pour exécuter l’application. Cela entraîne des temps de démarrage plus rapides et une utilisation réduite de la mémoire, mais présente certaines limitations sur les fonctionnalités prises en charge.

Avantages

  • Démarrage rapide : aucune compilation JIT n’est nécessaire au moment de l’exécution, ce qui accélère le démarrage de l’application.
  • Utilisation réduite de la mémoire : empreinte mémoire inférieure par rapport aux applications .NET traditionnelles.
  • Aucune dépendance d’exécution : l’application s’exécute sans nécessiter l’installation du runtime .NET.
  • Taille de déploiement plus petite : souvent plus petite que le déploiement autonome avec le runtime complet.

Inconvénients

  • Prise en charge limitée du framework : toutes les fonctionnalités et bibliothèques .NET ne sont pas compatibles avec Native AOT.
  • Temps de génération plus longs : la compilation vers du code natif prend plus de temps que les builds régulières.
  • Spécifique à la plateforme : doit être compilé séparément pour chaque plateforme et architecture cible.
  • Limitations du débogage : expérience de débogage plus complexe par rapport aux applications .NET régulières.

Pour plus d’informations sur le déploiement AOT natif, consultez déploiement AOT natif.

Publier

dotnet publish -c Release -r <RID> -p:PublishAot=true

  • -c Release

    Ce commutateur définit la configuration de build sur Release, qui est optimisée pour le déploiement de production.

  • -r <RID>

    Ce commutateur utilise un identificateur d’exécution (RID) pour spécifier la plateforme cible et garantit que les dépendances natives sont incluses (si nécessaire). Pour obtenir la liste des identificateurs d’exécution, consultez le catalogue RID (Runtime Identifier).

  • -p:PublishAot=true

    Cette propriété active la compilation AOT native, qui compile l’application directement en code natif.

La publication AOT native doit être configurée dans le fichier projet. Vous ne pouvez pas l’activer via l’interface utilisateur de publication de Visual Studio.

  1. Dans l’Explorateur de solutions, cliquez avec le bouton droit sur votre projet, puis sélectionnez Modifier le fichier projet.

  2. Ajoutez la propriété suivante à un <PropertyGroup>:

    <PublishAot>true</PublishAot>

  3. Enregistrez le fichier projet.

  4. Cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions , puis sélectionnez Publier.

  5. S’il s’agit de votre première publication, sélectionnez Dossier comme cible de publication, puis sélectionnez Suivant.

  6. Choisissez un emplacement de dossier ou acceptez la valeur par défaut, puis sélectionnez Terminer.

  7. Dans le profil de publication, sélectionnez Afficher tous les paramètres.

  8. Définissez le mode de déploiementsur autonome.

  9. Définissez le runtime cible sur votre plateforme souhaitée (par exemple, win-x64 pour Windows 64 bits).

  10. Sélectionnez Enregistrer , puis Publier.

Pour plus d’informations sur le déploiement AOT natif, consultez déploiement AOT natif.

Déploiement ReadyToRun

Lorsque vous publiez votre application avec la compilation ReadyToRun, vos assemblys d’application sont compilés en tant que format ReadyToRun (R2R). R2R est une forme de compilation anticipée (AOT) qui améliore les performances de démarrage en réduisant la quantité de travail nécessaire au compilateur juste-à-temps (JIT) à mesure que votre application se charge. Cette option de publication peut être utilisée avec les modes de déploiementautonomes et dépendants de l’infrastructure.

Les fichiers binaires ReadyToRun contiennent à la fois du code il (Intermediate Language) et de la version native du même code. Bien que les fichiers binaires R2R soient plus volumineux que les assemblys standard, ils offrent de meilleures performances de démarrage.

Avantages

  • Temps de démarrage amélioré : l’application passe moins de temps à exécuter le compilateur JIT au démarrage.
  • Meilleures performances de première utilisation : latence réduite pour l’exécution initiale des chemins de code.
  • Compatible avec le code existant : fonctionne avec la plupart des bibliothèques et infrastructures .NET sans modification.
  • Déploiement flexible : peut être combiné avec les modes de déploiement dépendant du framework et de déploiement autonome .

Inconvénients

  • Taille supérieure : l’application est plus grande sur le disque en raison de l’inclusion du code IL et du code natif.
  • Temps de génération plus longs : la compilation prend plus de temps que la publication standard.
  • Optimisations spécifiques à la plateforme : les meilleurs gains de performances nécessitent le ciblage de plateformes spécifiques.

Publier

dotnet publish -c Release -r <RID> -p:PublishReadyToRun=true

  • -c Release

    Ce commutateur définit la configuration de build sur Release, qui est optimisée pour le déploiement de production.

  • -r <RID>

    Ce commutateur utilise un identificateur d’exécution (RID) pour spécifier la plateforme cible et garantit que les dépendances natives sont incluses (si nécessaire). Pour obtenir la liste des identificateurs d’exécution, consultez le catalogue RID (Runtime Identifier).

  • -p:PublishReadyToRun=true

    Cette propriété active la compilation ReadyToRun, qui améliore les performances de démarrage en pré-compilation d’assemblys.

  1. Cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions , puis sélectionnez Publier.
  2. S’il s’agit de votre première publication, sélectionnez Dossier comme cible de publication, puis sélectionnez Suivant.
  3. Choisissez un emplacement de dossier ou acceptez la valeur par défaut, puis sélectionnez Terminer.
  4. Dans le profil de publication, sélectionnez Afficher tous les paramètres.
  5. Définissez le mode de déploiement sur autonome oudépendant de l’infrastructure.
  6. Définissez le runtime cible sur votre plateforme souhaitée (par exemple, win-x64 pour Windows 64 bits).
  7. Vérifiez la compilation ReadyToRun.
  8. Sélectionnez Enregistrer , puis Publier.

Pour plus d’informations sur le déploiement ReadyToRun, consultez compilation ReadyToRun.

Déploiement de conteneurs

Lorsque vous publiez votre application en tant que conteneur, le Kit de développement logiciel (SDK) .NET empaquette votre application et ses dépendances dans une image conteneur sans nécessiter de fichier Dockerfile distinct. Ce mode de déploiement crée une image conteneur complète qui peut être exécutée sur n’importe quel runtime de conteneur, tel que Docker ou Podman. Le déploiement de conteneur simplifie le processus de conteneurisation en éliminant la nécessité d’écrire et de gérer des fichiers Dockerfile tout en fournissant des images de base optimisées.

À compter du Kit de développement logiciel (SDK) .NET 8.0.200, la prise en charge des conteneurs est incluse par défaut et ne nécessite pas de packages NuGet supplémentaires. Pour les applications console, vous devrez peut-être activer explicitement la prise en charge du conteneur en définissant la EnableSdkContainerSupport propriété truesur .

Conseil

Pour plus d’informations sur les paramètres de projet liés aux conteneurs, consultez Containerize une référence d’application .NET.

Avantages

  • Conteneurisation simplifiée : il n’est pas nécessaire d’écrire ou de gérer des fichiers Dockerfile pour des scénarios de base.
  • Images de base optimisées : utilise des images de base fournies par Microsoft et optimisées avec les dernières mises à jour de sécurité.
  • Environnement cohérent : garantit un environnement d’exécution cohérent entre le développement, le test et la production.
  • Distribution facile : les images conteneur peuvent être facilement partagées et déployées dans différents environnements.
  • Isolation de la plateforme : les applications s’exécutent dans des conteneurs isolés, ce qui réduit les conflits entre les applications.

Inconvénients

  • Dépendance du runtime de conteneur : l’environnement cible doit avoir un runtime de conteneur installé.
  • Taille de l’image : les images conteneur sont généralement plus volumineuses que d’autres méthodes de déploiement.
  • Courbe d’apprentissage : nécessite une compréhension des concepts et des outils de conteneur.
  • Personnalisation limitée : moins de flexibilité par rapport aux fichiers Dockerfile personnalisés pour les scénarios complexes.

Publier

dotnet publish -c Release [-r <RID>] /t:PublishContainer

  • -c Release

    Ce commutateur définit la configuration de build sur Release, qui est optimisée pour le déploiement de production.

  • -r <RID>

    Ce commutateur utilise un identificateur d’exécution (RID) pour spécifier la plateforme cible et garantit que les dépendances natives sont incluses (si nécessaire). Pour obtenir la liste des identificateurs d’exécution, consultez le catalogue RID (Runtime Identifier).

  • -t:PublishContainer

    Cette cible publie l’application en tant qu’image conteneur.

Vous pouvez également utiliser l’approche de profil de publication :

dotnet publish -c Release [-r <RID>] -p:PublishProfile=DefaultContainer

  • -p:PublishProfile=DefaultContainer

    Ce profil déclenche le processus de publication de conteneur.

  1. Cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions , puis sélectionnez Publier.
  2. Sélectionnez Container Registry comme cible de publication, puis sélectionnez Suivant.
  3. Choisissez votre registre de conteneurs cible (par exemple , Azure Container Registry, Docker Hub ou Generic Registry) et sélectionnez Suivant.
  4. Configurez les détails de connexion et l’authentification du Registre.
  5. Dans le profil de publication, sélectionnez Afficher tous les paramètres.
  6. Définissez le mode de déploiement sur autonome oudépendant du framework en fonction de vos besoins.
  7. Définissez le runtime cible sur votre plateforme souhaitée (par exemple, linux-x64 pour les conteneurs Linux).
  8. Configurez des paramètres spécifiques au conteneur, tels que le nom de l’image et les balises.
  9. Sélectionnez Enregistrer , puis Publier.

Pour plus d’informations sur le déploiement de conteneurs, consultez la vue d’ensemble de la création du conteneur du Kit de développement logiciel (SDK) .NET.

Voir aussi

  • Last updated on