Restauration par progression du runtime de déploiement autonome

Les déploiements d’applications autonomes .NET Core incluent à la fois les bibliothèques .NET Core et le runtime .NET Core. À compter du SDK .NET Core 2.1 (version 2.1.300), un déploiement d’applications autonome publie le runtime du correctif le plus élevé sur votre machine. Par défaut, dotnet publish pour un déploiement autonome sélectionne la dernière version installée dans le cadre du SDK sur la machine de publication. Ainsi, votre application déployée peut exécuter des correctifs de sécurité (et d’autres correctifs) disponibles pendant publish. L’application doit être republiée pour obtenir un nouveau correctif. Les applications autonomes sont créées en spécifiant -r <RID> dans la commande dotnet publish ou en spécifiant l’identificateur du runtime (RID) dans le fichier projet (csproj/vbproj) ou sur la ligne de commande.

Vue d’ensemble de la restauration par progression d’une version de correctif

restore, build et publish sont des commandes dotnet exécutables séparément. Le choix du runtime fait partie de l’opération restore, et non de publish ou build. Si vous appelez publish, la dernière version du correctif est choisie. Si vous appelez publish avec l’argument --no-restore, alors vous risquez de ne pas obtenir la version de correctif voulue, car un restore antérieur n’a peut-être pas été exécuté avec la nouvelle stratégie de publication des applications autonomes. Dans ce cas, une erreur de build est générée avec un texte similaire au suivant :

« Le projet a été restauré à l’aide de Microsoft.NETCore.App version 2.0.0, mais avec les paramètres actuels, la version 2.0.6 serait plutôt utilisée. Pour résoudre ce problème, vérifiez que les mêmes paramètres sont utilisés pour la restauration et pour les opérations qui suivent, comme la génération ou la publication. En général, ce problème peut se produire si la propriété RuntimeIdentifier est définie lors de la génération ou de la publication, mais pas lors de la restauration.

Notes

restore et build peut être exécutées implicitement dans le cadre d’une autre commande, comme publish. Quand vous exécutez une commande implicitement dans le cadre d’une autre commande, un contexte supplémentaire est fourni afin de produire les artefacts adéquats. Quand vous exécutez une commande publish avec un runtime (par exemple, dotnet publish -r linux-x64), la commande restore implicite restaure les packages du runtime linux-x64. Si vous appelez restore explicitement, les packages du runtime ne sont pas restaurés par défaut, car ce contexte n’est pas fourni.

Comment éviter la restauration pendant la publication

L’exécution de restore dans le cadre de l’opération publish peut ne pas convenir à votre scénario. Pour éviter restore pendant publish quand vous créez des applications autonomes, procédez effectuez les étapes suivantes :

• Définissez la propriété RuntimeIdentifiers sur une liste séparée par des points-virgules de tous les RID à publier.
• Définissez la propriété TargetLatestRuntimePatch sur true.

Argument No-restore avec des options dotnet publish

Pour créer à la fois des applications autonomes et des applications dépendant du framework avec le même fichier projet, quand vous voulez utiliser l’argument --no-restore avec dotnet publish, choisissez l’une des possibilités suivantes :

1. Préférez le comportement dépendant du framework. Si l’application dépend du framework, il s’agit du comportement par défaut. Si l’application est autonome et peut utiliser un runtime local 2.1.0 sans correctif, définissez TargetLatestRuntimePatch sur false dans le fichier projet.

2. Préférez le comportement autonome. Si l’application est autonome, il s’agit du comportement par défaut. Si l’application dépend du framework et nécessite l’installation du dernier correctif, définissez TargetLatestRuntimePatch sur true dans le fichier projet.

3. Prenez le contrôle explicite de la version du framework du runtime en définissant RuntimeFrameworkVersion sur la version de correctif spécifique dans le fichier projet.