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 un utilisateur exécute votre application.
La publication de votre application en mode autonome produit une application qui inclut l'environnement d'exécution 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 que dépendant du framework conduit à une application n'incluant que votre application elle-même 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 de l’infrastructure peuvent être créées sans exécutable, et ces applications sont multiplateformes.
Quand un exécutable est généré, vous pouvez spécifier la plateforme cible avec un identificateur d’exécution (RID). Pour plus d’informations sur les RID, consultez le catalogue RID .NET
Le tableau suivant présente les commandes utilisées pour publier une application en tant que framework dépendant ou autonome :
| Type | Commande |
|---|---|
| exécutable dépendant du framework pour la plate-forme actuelle. | dotnet publish |
| exécutable dépendant du framework pour une plate-forme spécifique. | dotnet publish -r <RID> |
| binaire dépendant du framework. | dotnet publish |
| exécutable autonome. | dotnet publish -r <RID> --self-contained |
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 en mode autonome inclut le runtime .NET avec l'application. Les utilisateurs de l'application n'ont pas à se soucier de l'installation de .NET avant d'exécuter l'application. La publication d’une application en tant que dépendant du framework n’inclut pas le runtime .NET ; seules l’application et les dépendances tierces sont incluses.
Les commandes suivantes produisent un exécutable :
| Type | Commande |
|---|---|
| exécutable dépendant du framework pour la plate-forme actuelle. | dotnet publish |
| exécutable dépendant du framework pour une plate-forme spécifique. | dotnet publish -r <RID> |
| exécutable autonome. | dotnet publish -r <RID> --self-contained |
Produire un binaire multiplateforme
Les fichiers binaires multiplateformes sont créés lorsque vous publiez votre application en tant quedépendant de l’infrastructure dotnet <filename.dll> et peuvent être exécutées sur n’importe quelle plateforme.
Les fichiers binaires multiplateformes peuvent être exécutés sur n’importe quel système d’exploitation tant que le runtime .NET ciblé est 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 elle est configurée pour un transfert vers une version plus récente. Pour plus d’informations, consultez Restauration par progression des applications dépendantes du framework.
Vous pouvez choisir d’exécuter l’application en tant qu’exécutable spécifique à la plateforme ou en tant que binaire multiplateforme via dotnet commande. Il ne doit y avoir aucune différence de comportement de l’application lors du lancement de l’exécutable spécifique à la plateforme par rapport à la commande dotnet pour les applications serveur ordinaires Lancement via un exécutable spécifique à la plateforme vous offre une meilleure intégration au système d’exploitation sous-jacent. Par exemple:
- Vous voyez le nom exécutable de l’application dans votre liste de processus et non
dotnet, ce qui peut prêter à confusion s’il en existe plusieurs. - Vous pouvez personnaliser l’exécutable spécifique à la plateforme avec des fonctionnalités spécifiques au système d’exploitation. Par exemple, voir cette discussion sur la configuration de la taille de la pile par défaut sous Windows.
La commande suivante produit un binaire multiplateforme :
| Type | Commande |
|---|---|
| binaire multiplateforme dépendant du framework. | dotnet publish |
Publier comme dépendant du framework
Les applications publiées en tant que dépendantes de l’infrastructure sont multiplateformes et n’incluent pas le runtime .NET. L’utilisateur de votre application est requis pour 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. La dll est multiplateforme, alors que l’exécutable ne l’est pas. Par exemple, si vous publiez une application nommée word_reader et cible 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. Si l’application utilise un package NuGet qui a des implémentations spécifiques à la plateforme, les dépendances pour toutes les plateformes sont copiées dans le dossier publier\runtimes\{platform}.
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.
Dépendant de la plateforme et de l’infrastructure
Vous pouvez publier une application qui dépend du framework et qui est spécifique à la plateforme en transmettant les paramètres -r <RID> à la commande dotnet publish. Publier de cette manière est identique à publier en fonction du framework, sauf que les dépendances spécifiques à la plate-forme sont gérées différemment. Si l’application utilise un package NuGet qui a des implémentations spécifiques à la plateforme, seules les dépendances de la plateforme ciblée sont copiées. Ces dépendances sont copiées directement dans le dossier de publication.
Bien que techniquement le binaire produit soit multiplateforme, en ciblant une plateforme spécifique, votre application n’est pas garantie d’exécuter plusieurs plateformes. Vous pouvez exécuter dotnet <filename.dll>, mais l’application peut se bloquer lorsqu’elle tente d’accéder aux dépendances spécifiques à la plateforme manquantes.
Pour plus d’informations sur les identificateurs de runtime, consultez Catalogue RID .NET.
Avantages
Petit déploiement
Seule 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.Le binaire multiplateforme
Votre application et toute bibliothèque basée sur .NET s’exécutent sur d’autres systèmes d’exploitation. Vous n’avez pas besoin de définir une plateforme cible pour votre application. Pour plus d’informations sur le format de fichier .NET, consultez format de fichier d'assemblage .NET.utilise le dernier environnement d'exécution corrigé
L’application utilise le dernier runtime (dans la famille principale-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écessite la préinstallation du runtime
Votre application ne peut s’exécuter que si la version de .NET cible votre application est déjà installée sur le système hôte. Vous pouvez configurer le comportement de migration pour que l’application exige une version spécifique de .NET ou autorise 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 .NET et les bibliothèques soient mis à jour sur l’ordinateur sur lequel l’application est exécutée. Dans de rares cas, cela peut modifier le comportement de votre application si vous utilisez les bibliothèques .NET, que la plupart des applications font. Vous pouvez configurer la façon dont votre application utilise des versions plus récentes de .NET. Pour plus d’informations, consultez Restauration par progression des applications dépendantes du framework.
Exemples
Publiez une application sous la forme d’une application multiplateforme et dépendante de l’infrastructure. Un exécutable qui cible votre plateforme actuelle est créé avec le fichier dll
dotnet publish
Publier une application en tant que spécifique à la plate-forme et dépendante du framework. Un exécutable Linux 64 bits est créé avec le fichier dll
dotnet publish -r linux-x64
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 les bibliothèques .NET et le runtime cible. L’application est isolée d’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.
Vous pouvez publier une application autonome en passant le paramètre --self-contained à la commande dotnet publish. Le fichier binaire exécutable est généré pour la plateforme cible spécifiée. Par exemple, si vous avez une application nommée word_readeret que vous publiez un exécutable autonome pour Windows, un fichier word_reader.exe est créé. Lors de la publication pour Linux ou macOS, un fichier word_reader est créé. La plateforme cible et l’architecture sont spécifiées avec le paramètre -r <RID> pour 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ôler la version .NET
Vous contrôlez la version de .NET déployée avec votre application.Ciblage spécifique à la plate-forme
Étant donné que vous devez publier votre application pour chaque plateforme, vous savez où votre application s’exécute. Si .NET introduit une nouvelle plateforme, les utilisateurs ne peuvent pas exécuter votre application sur cette plateforme tant que vous n’avez pas publié une version ciblant cette plateforme. Vous pouvez tester votre application en cas de problèmes de compatibilité avant que vos utilisateurs n’exécutent votre application sur la nouvelle plateforme.
Inconvénients
déploiements plus volumineux
Étant donné que votre application inclut le runtime .NET et toutes vos dépendances d’application, la taille de téléchargement et l’espace disque dur requis sont supérieurs à une version dépendant de l’infrastructure.Conseil
Vous pouvez réduire la taille de votre déploiement sur des systèmes Linux d’environ 28 Mo en utilisant .NET le mode invariant de globalisation. Cela force votre application à traiter toutes les cultures comme la culture invariante.
Conseil
L'élagage de l'IL peut réduire davantage la taille de votre déploiement.
Plus difficile de mettre à jour la version .NET
Le runtime .NET (distribué avec votre application) ne peut être mis à niveau qu’en publiant une nouvelle version de votre application.
Exemples
Publiez une application autonome. Un exécutable macOS 64 bits est créé.
dotnet publish -r osx-x64 --self-contained
Publiez une application autonome. Un exécutable Windows 64 bits est créé.
dotnet publish -r win-x64 --self-contained
Publier avec des images ReadyToRun
La publication avec des images ReadyToRun améliore le temps de démarrage de votre application au coût d’augmentation de la taille de votre application. Pour plus d’informations, consultez ReadyToRun.
Avantages
- temps de démarrage amélioré
L’application passe moins de temps à exécuter le JIT.
Inconvénients
- taille plus grande
L’application est 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 --self-contained -p:PublishReadyToRun=true
Publiez une application autonome et prête à fonctionner. Un exécutable Windows 64 bits est créé.
dotnet publish -c Release -r win-x64 --self-contained -p:PublishReadyToRun=true
