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

Les applications que vous créez avec .NET peuvent être publiées dans deux modes différents, et le mode affecte la façon dont l’utilisateur exécute votre application.

La publication de votre application en tant qu’application autonome produit une application qui inclut le runtime et les bibliothèques .NET, ainsi que votre application et ses dépendances. Les utilisateurs de l’application peuvent l’exécuter sur un ordinateur sur lequel le runtime .NET n’est pas installé.

La publication de votre application en tant qu’application dépendante du framework produit une application qui inclut uniquement votre application et ses dépendances. Les utilisateurs de l’application doivent installer séparément le runtime .NET.

Les deux modes de publication produisent un exécutable spécifique à la plateforme par défaut. Les applications dépendantes du framework peuvent être créées sans exécutable, et ces applications sont multiplateformes.

Quand un exécutable est produit, vous pouvez spécifier la plateforme cible avec un identificateur de runtime (RID). Pour plus d’informations sur les identificateurs de runtime, consultez Catalogue RID .NET.

Le tableau suivant présente les commandes utilisées pour publier une application en tant qu’application dépendante du framework ou autonome, selon la version du kit SDK :

Pour plus d’informations, consultez Commande .NET dotnet publish.

Produire un exécutable

Les exécutables ne sont pas multiplateformes. Ils sont spécifiques à un système d’exploitation et à une architecture de processeur. Lors de la publication de votre application et de la création d’un exécutable, vous pouvez publier l’application en tant qu’application autonome ou dépendante du framework. La publication d’une application comme application autonome inclut le runtime .NET avec l’application, et les utilisateurs de l’application n’ont pas à se soucier de l’installation de .NET avant d’exécuter l’application. Les applications publiées en tant qu’applications dépendantes du framework n’incluent pas le runtime ni les bibliothèques .NET ; seules l’application et les dépendances tierces sont incluses.

Les commandes suivantes produisent un exécutable :

Produire un binaire multiplateforme

Les binaires multiplateformes sont créés lorsque vous publiez votre application en tant qu’application dépendante du framework, sous la forme d’un fichier dll. Le fichier dll est nommé d’après votre projet. Par exemple, si vous avez une application nommée word_reader, un fichier nommé word_reader.dll est créé. Les applications publiées de cette façon sont exécutées avec la commande dotnet <filename.dll> et peuvent être exécutées sur n’importe quelle plateforme.

Les binaires multiplateformes peuvent être exécutés sur n’importe quel système d’exploitation à condition que le runtime .NET ciblé soit déjà installé. Si le runtime .NET ciblé n’est pas installé, l’application peut s’exécuter à l’aide d’un runtime plus récent si l’application est configurée pour une restauration par progression. Pour plus d’informations, consultez Restauration par progression des applications dépendantes du framework.

La commande suivante produit un binaire multiplateforme :

Publier comme dépendant du framework

Les applications publiées en tant qu’applications dépendantes du framework sont multiplateformes et n’incluent pas le runtime .NET. L’utilisateur de votre application doit installer le runtime .NET.

La publication d’une application en tant qu’application dépendante du framework produit un binaire multiplateforme sous la forme d’un fichier dll et un exécutable spécifique à la plateforme qui cible votre plateforme actuelle. Le dll est multiplateforme alors que l’exécutable ne l’est pas. Par exemple, si vous publiez une application nommée word_reader et ciblez Windows, un exécutable word_reader.exe est créé avec word_reader.dll. Lorsque vous ciblez Linux ou macOS, un exécutable word_reader est créé avec word_reader.dll. Pour plus d’informations sur les identificateurs de runtime, consultez Catalogue RID .NET.

Le binaire multiplateforme de votre application peut être exécuté avec la commande dotnet <filename.dll> et peut être exécuté sur n’importe quelle plateforme. Si l’application utilise un package NuGet qui a des implémentations spécifiques à la plateforme, les dépendances de toutes les plateformes sont copiées dans le dossier de publication avec l’application.

Vous pouvez créer un exécutable pour une plateforme spécifique en transmettant les paramètres -r <RID> --self-contained false à la commande dotnet publish. Quand le paramètre -r est omis, un exécutable est créé pour votre plateforme actuelle. Tous les packages NuGet qui ont des dépendances spécifiques à la plateforme pour la plateforme ciblée sont copiés dans le dossier de publication. Si vous n’avez pas besoin d’un exécutable spécifique à la plateforme, vous pouvez spécifier <UseAppHost>False</UseAppHost> dans le fichier projet. Pour plus d’informations, consultez Référence MSBuild pour les projets de kit SDK .NET.

Avantages

• Déploiement à petite échelle
  Seules votre application et ses dépendances sont distribuées. Le runtime et les bibliothèques .NET sont installés par l’utilisateur et toutes les applications partagent le runtime.

• Multiplateforme
  Votre application et n’importe quelle bibliothèque basée sur .NET s’exécute sur d’autres systèmes d’exploitation. Vous n’avez pas besoin de définir une plateforme cible pour votre application. Pour obtenir des informations sur le format de fichier .NET, consultez Format de fichier d’assembly .NET.

• Utilisation du dernier runtime corrigé
  L’application utilise le dernier runtime (dans la famille majeure-mineure ciblée de .NET) installé sur le système cible. Cela signifie que votre application utilise automatiquement la dernière version corrigée du runtime .NET. Ce comportement par défaut peut être remplacé. Pour plus d’informations, consultez Restauration par progression des applications dépendantes du framework.

Inconvénients

• Nécessité de préinstaller le runtime
  Votre application peut s’exécuter seulement si la version de .NET ciblée par votre application est déjà installée sur le système hôte. Vous pouvez configurer le comportement de restauration par progression pour l’application afin d’exiger une version spécifique de .NET ou d’autoriser une version plus récente de .NET. Pour plus d’informations, consultez Restauration par progression des applications dépendantes du framework.

• .NET peut changer
  Il est possible que le runtime et les bibliothèques .NET soient mis à jour sur la machine où l’application est exécutée. Dans de rares cas, cela peut changer le comportement de votre application si vous utilisez les bibliothèques .NET, comme le font la plupart des applications. Vous pouvez configurer la façon dont votre application utilise les versions plus récentes de .NET. Pour plus d’informations, consultez Restauration par progression des applications dépendantes du framework.

L’inconvénient suivant s’applique uniquement au kit SDK .NET Core 2.1.

• Utilisez la commande dotnet pour démarrer l’application
  Les utilisateurs doivent exécuter la commande dotnet <filename.dll> pour démarrer votre application. Le kit SDK .NET Core 2.1 ne produit pas d’exécutables spécifiques à la plateforme pour les applications publiées comme dépendantes du framework.

Exemples

Publiez une application multiplateforme comme dépendante du framework. Un exécutable qui cible votre plateforme actuelle est créé avec le fichier dll.

dotnet publish

Publiez une application multiplateforme comme dépendante du framework. Un exécutable Linux 64 bits est créé avec le fichier dll. Cette commande ne fonctionne pas avec le kit SDK .NET Core 2.1.

dotnet publish -r linux-x64 --self-contained false

Publier comme autonome

La publication de votre application en tant qu’application autonome produit un exécutable spécifique à la plateforme. Le dossier de publication de sortie contient tous les composants de l’application, y compris le runtime cible et les bibliothèques .NET. L’application est isolée des autres applications .NET et n’utilise pas un runtime partagé installé localement. L’utilisateur de votre application n’est pas tenu de télécharger et d’installer .NET.

Le binaire exécutable est produit pour la plateforme cible spécifiée. Par exemple, si vous avez une application nommée word_reader et que vous publiez un exécutable autonome pour Windows, un fichier word_reader.exe est créé. En publiant pour Linux ou macOS, un fichier word_reader est créé. La plateforme et l’architecture cibles sont spécifiées avec le paramètre -r <RID> de la commande dotnet publish. Pour plus d’informations sur les identificateurs de runtime, consultez Catalogue RID .NET.

Si l’application a des dépendances spécifiques à la plateforme, telles qu’un package NuGet contenant des dépendances spécifiques à la plateforme, celles-ci sont copiées dans le dossier de publication avec l’application.

Avantages

• Contrôle de la version de .NET
  Vous contrôlez la version de .NET qui est déployée avec votre application.

• Ciblage spécifique à la plateforme
  Étant donné que vous devez publier votre application pour chaque plateforme, vous savez où votre application s’exécutera. Si .NET introduit une nouvelle plateforme, les utilisateurs ne peuvent pas exécuter votre application sur cette plateforme tant que vous ne publiez pas une version ciblant cette plateforme. Vous pouvez tester votre application pour rechercher des problèmes de compatibilité avant que vos utilisateurs exécutent votre application sur la nouvelle plateforme.

Inconvénients

• Déploiements plus importants
  Étant donné que votre application inclut le runtime .NET et toutes les dépendances de votre application, la taille de téléchargement et l’espace sur le disque dur requis sont plus grands que pour une version dépendante du framework.

  Conseil

  Vous pouvez réduire la taille de votre déploiement sur les systèmes Linux d’environ 28 Mo à l’aide du mode invariant de globalisation .NET. Cela force votre application à traiter toutes les cultures comme la culture invariante.

  Conseil

  Le découpage IL peut réduire encore la taille de votre déploiement.

• Mise à jour plus difficile de la version de .NET
  Le runtime .NET (distribué avec votre application) ne peut être mis à niveau qu’en publiant une nouvelle version de votre application. Toutefois, .NET met à jour les correctifs de sécurité critiques en fonction des besoins de la bibliothèque de framework sur la machine où votre application s’exécute. Vous êtes responsable de la validation de bout en bout pour ce scénario d'installation de correctifs de sécurité.

Exemples

Publiez une application comme application autonome. Un exécutable macOS 64 bits est créé.

dotnet publish -r osx-x64

Publiez une application comme application autonome. Un exécutable Windows 64 bits est créé.

dotnet publish -r win-x64

Publier avec des images ReadyToRun

La publication avec des images ReadyToRun améliore le temps de démarrage de votre application au prix d’une augmentation de la taille de votre application. Pour publier avec ReadyToRun, consultez ReadyToRun pour plus d’informations.

Avantages

• Amélioration du temps de démarrage
  L’application passera moins de temps à exécuter le JIT.

Inconvénients

• Plus grande taille
  L’application sera plus grande sur le disque.

Exemples

Publiez une application comme autonome et ReadyToRun. Un exécutable macOS 64 bits est créé.

dotnet publish -c Release -r osx-x64 -p:PublishReadyToRun=true

Publiez une application comme autonome et ReadyToRun. Un exécutable Windows 64 bits est créé.

dotnet publish -c Release -r win-x64 -p:PublishReadyToRun=true

Voir aussi

• Déploiement d’applications .NET avec l’interface CLI .NET.
• Déploiement d’applications .NET Core avec Visual Studio.
• Catalogue d’identificateurs de runtime (RID) .NET.
• Sélectionner la version de .NET à utiliser.