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 Visual Studio.

Pour obtenir un bref tutoriel sur la publication, consultez Tutorial : Publier une application console .NET.

Pour obtenir un bref tutoriel sur la publication, consultez Tutorial : Publier une application console .NET.

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é les .NET Runtime appropriés 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 la .NET runtime préinstallé.

• Publication dépendante du framework
  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é 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 .NET catalogue RID.

Principes de base de la publication

Le 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 binaire qui cible .NET 9 est créé.

Si vous souhaitez cibler plusieurs frameworks, vous pouvez définir le 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 paramètre.

dotnet publish -c Release -f net9.0

Le répertoire de sortie par défaut de la commande est . Par exemple, publie sur . 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 des Artifacts.

Dans Visual Studio, créez des profils de publication distincts pour chaque framework 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 propriété , qui est défini par défaut sur . Pour publier uniquement la DLL portable sans exécutable spécifique à la plateforme, définissez-la sur la ligne de commande () 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 Explorateur de solutions et sélectionnez Publish.
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 Target Runtime 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 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 similaire à myapp.exe sur Windows ou simplement myapp sur d’autres plateformes.

Votre application est configurée pour cibler une version spécifique de .NET. Ce .NET runtime ciblé doit être 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 mise à jour vers le dernier correctif de sécurité .NET disponible dans l'environnement d'exécution de l'application. Pour plus d’informations sur la liaison de version au moment de la compilation, consultez Select the .NET version to use.

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.
• Cross-platform : l’application et toutes les bibliothèques basées sur .NET s’exécutent sur d’autres systèmes d’exploitation.
• Utilise le dernier runtime corrigé : l’application utilise le dernier runtime installé dans l’environnement.

Inconvénients

• Requires préinstallation du runtime : l’application ne peut s’exécuter que 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 . Vous pouvez exécuter l’exécutable apphost directement au lieu d’appeler , 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, le shadow stack de Control-flow Enforcement Technology (CET) est activé par défaut à partir de .NET 9. Les atténuations appliquées à 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 sdk .NET de créer un déploiement dépendant du framework.

1. Cliquez avec le bouton droit sur le projet dans Explorateur de solutions et sélectionnez Publish.
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 Target Runtime 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 .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’exécution .NET peut également être personnalisé par exécution. La variable d’environnement peut être utilisée pour pointer vers l’emplacement personnalisé. Pour plus d’informations sur toutes les options de configuration DOTNET_ROOT, consultez .NET variables d’environnement.

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

1. Effacez d’abord les variables d’environnement, ce qui signifie que toutes les variables d’environnement commencent par le texte .
2. Définissez , et uniquement , 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 AppHostDotNetSearch et AppHostRelativeDotNet.

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

• : dossier de l'application exécutable
• : chemin relatif à l’exécutable de l’application
• : valeur des variables d’environnement
• : emplacements d’installation globaux enregistrés et par défaut

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

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

Déploiement multiplateforme de DLL

Vous pouvez également publier votre application en tant que DLL multiplateforme sans exécutable spécifique à la plateforme. Dans ce mode, un fichier est créé dans le dossier de sortie de publication. Pour exécuter votre application, accédez au dossier de sortie et utilisez la 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 Explorateur de solutions et sélectionnez Publish.
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 dépendant du framework.
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 requis 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 se met pas à jour vers le dernier correctif de sécurité .NET disponible. Pour plus d’informations sur la liaison de version au moment de la compilation, consultez Select the .NET version to use.

Avantages

• Control .NET version : contrôler 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

• Larger deployments : é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 de framework.
• Plus difficile de mettre à jour la version .NET : l’environnement d’exécution .NET peut seulement être mis à niveau en publiant une nouvelle version de l’application.

Conseil

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

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 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 Explorateur de solutions et sélectionnez Publish.
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 Target Runtime 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 Explorateur de solutions et sélectionnez Publish.
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 Target Runtime 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 de la mémoire réduite : empreinte mémoire inférieure par rapport aux applications de .NET traditionnelles.
• No runtime dependency : l’application s’exécute sans nécessiter d’installation .NET runtime.
• Taille de déploiement plus petite : souvent plus petite que le déploiement autonome avec le runtime complet.

Inconvénients

• Prise en charge de l’infrastructure délimitée : toutes les fonctionnalités et bibliothèques .NET ne sont pas compatibles avec L’AOT natif.
• 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 de 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 Visual Studio.

1. Dans Explorateur de solutions, cliquez avec le bouton droit sur votre projet, puis sélectionnez Fichier projetedit.

2. Ajoutez la propriété suivante à un :

   <PublishAot>true</PublishAot>
   

3. Enregistrez le fichier projet.

4. Cliquez avec le bouton droit sur le projet dans Explorateur de solutions et sélectionnez Publish.

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 Target Runtime 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 du 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 Explorateur de solutions et sélectionnez Publish.
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 Target Runtime sur votre plateforme souhaitée (par exemple, win-x64 pour Windows 64 bits).
7. Vérifiez Activer 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, la .NET SDK 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 de .NET SDK 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 propriété sur .

Conseil

Pour plus d’informations sur les paramètres de projet liés aux conteneurs, consultez Containerize a .NET app reference.

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 la méthode du 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 Explorateur de solutions et sélectionnez Publish.
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 Next.
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 .NET vue d’ensemble de la création de conteneurs sdk.

Voir aussi

• Catalogue des RID (.NET Runtime Identifier)
• Sélectionnez la version de .NET à utiliser
• Publication pour macOS