Partager via

Sélectionnez la version .NET à utiliser

Cet article explique les stratégies utilisées par les outils, sdk et runtime .NET pour sélectionner des versions. Ces stratégies fournissent un équilibre entre l’exécution d’applications à l’aide des versions spécifiées et la facilité de mise à niveau des machines développeur et utilisateur final. Ces stratégies permettent d’activer :

  • Déploiement simple et efficace de .NET, y compris les mises à jour de sécurité et de fiabilité.
  • Utilisez les derniers outils et commandes indépendamment du runtime cible.

La sélection de version se produit :

Le reste de ce document examine ces quatre scénarios.

Le Kit de développement logiciel (SDK) utilise la dernière version installée

Les commandes du Kit de développement logiciel (SDK) incluent dotnet new et dotnet run. L’interface CLI .NET doit choisir une version du Kit de développement logiciel (SDK) pour chaque commande dotnet. Il utilise le dernier SDK installé sur l’ordinateur par défaut, même si :

  • Le projet cible une version antérieure du runtime .NET.
  • La dernière version du Kit de développement logiciel (SDK) .NET est une version préliminaire.

Vous pouvez tirer parti des dernières fonctionnalités et améliorations du Kit de développement logiciel (SDK) tout en ciblant les versions antérieures du runtime .NET. Vous pouvez cibler différentes versions du runtime de .NET à l’aide des mêmes outils sdk.

Dans certains cas, vous devrez peut-être utiliser une version spécifique du Kit de développement logiciel (SDK). Vous spécifiez cette version dans un fichier global.json.

global.json pouvez être placé n’importe où dans la hiérarchie de fichiers. Vous décidez des projets auxquels s’applique une global.json en fonction de sa place dans le système de fichiers. L’interface CLI .NET recherche un fichier global.json de manière itérative qui navigue vers le haut du répertoire de travail actuel (ce qui n’est pas nécessairement le même que le répertoire du projet). Le premier fichier global.json trouvé spécifie la version utilisée. Si cette version du SDK est installée, cette version est utilisée. Si le Kit de développement logiciel (SDK) spécifié dans l'global.json est introuvable, l’interface CLI .NET utilise règles de correspondance pour sélectionner un KIT de développement logiciel (SDK) compatible ou échoue si aucune solution n’est trouvée.

L’exemple suivant montre la syntaxe global.json :

{
  "sdk": {
    "version": "5.0.0"
  }
}

Le processus de sélection d’une version du Kit de développement logiciel (SDK) est le suivant :

  1. dotnet recherche un fichier global.json de manière itérative en remontant le chemin depuis le répertoire de travail actuel.
  2. dotnet utilise le Kit de développement logiciel (SDK) spécifié dans la première global.json trouvée.
  3. dotnet utilise le SDK installé le plus récent si aucun global.json n’est trouvé.

Pour plus d’informations sur la sélection de la version du SDK, consultez les sections Règles de correspondance et rollForward de l’article vue d’ensemble de global.json.

Mise à jour de la version du Kit de développement logiciel (SDK)

Il est important de mettre à jour régulièrement vers la dernière version du Kit de développement logiciel (SDK) pour adopter les dernières fonctionnalités, améliorations des performances et correctifs de bogues. Pour rechercher facilement les mises à jour du Kit de développement logiciel (SDK), utilisez la commande dotnet sdk check. En outre, si vous sélectionnez une version spécifique à l’aide de global.json, envisagez d’utiliser un outil tel que Dependabot pour mettre à jour automatiquement la version épinglée du Kit de développement logiciel (SDK) à mesure que de nouvelles versions deviennent disponibles.

Les monikers de framework cible définissent les API au moment de la génération

Vous générez votre projet par rapport aux API définies dans un moniker de framework cible (TFM). Vous spécifiez l’infrastructure cible dans le fichier projet. Définissez l’élément TargetFramework dans votre fichier projet, comme illustré dans l’exemple suivant :

<TargetFramework>net8.0</TargetFramework>

Vous pouvez générer votre projet par rapport à plusieurs TFM. La définition de plusieurs frameworks cibles est plus courante pour les bibliothèques, mais peut également être effectuée avec des applications. Pour cela, vous devez spécifier une propriété TargetFrameworks (pluriel de TargetFramework). Les frameworks cibles sont délimités par des points-virgules, comme illustré dans l’exemple suivant :

<TargetFrameworks>net8.0;net47</TargetFrameworks>

Un SDK donné prend en charge un ensemble fixe de frameworks, limité au framework cible du runtime avec lequel il est fourni. Par exemple, le Kit de développement logiciel (SDK) .NET 8 inclut le runtime .NET 8, qui est une implémentation du framework cible net8.0. Le SDK .NET 8 prend en charge net7.0, net6.0et net5.0, mais pas net9.0 (ou version ultérieure). Vous installez le Kit de développement logiciel (SDK) .NET 9 pour compiler pour net9.0.

.NET Standard

.NET Standard était un moyen de cibler une surface d’API partagée par différentes implémentations de .NET. À compter de la version de .NET 5, qui est une norme d’API elle-même, .NET Standard a peu de pertinence, à l’exception d’un scénario : .NET Standard est utile lorsque vous souhaitez cibler .NET et .NET Framework. .NET 5 implémente toutes les versions .NET Standard.

Pour plus d’informations, consultez .NET 5 et .NET Standard.

Les applications dépendantes du framework font l’objet d’une restauration par progression

Lorsque vous exécutez une application à partir du code source avec dotnet run, à partir d’un déploiement dépendant de l’infrastructure avec dotnet myapp.dll, ou d’un exécutable dépendant de l’infrastructure avec myapp.exe, l’exécutable dotnet est le hôte de l’application.

L’hôte choisit la dernière version de correctif installée sur l’ordinateur. Par exemple, si vous avez spécifié net5.0 dans votre fichier projet et que 5.0.2 est le dernier runtime .NET installé, le runtime 5.0.2 est utilisé.

Si aucune version 5.0.* acceptable n’est trouvée, une nouvelle version 5.* est utilisée. Par exemple, si vous avez spécifié net5.0 et que seule 5.1.0 est installée, l’application s’exécute à l’aide du runtime 5.1.0. Ce comportement est appelé « restauration de version mineure ». Les versions antérieures ne seront pas prises en compte. Quand aucun runtime acceptable n’est installé, l’application ne s’exécute pas.

Quelques exemples d’utilisation illustrent le comportement, si vous ciblez la version 5.0 :

  • ✔️ 5.0 est spécifié. 5.0.3 est la version de correctif la plus élevée installée. 5.0.3 est utilisé.
  • ❌ 5.0 est spécifié. Aucune version 5.0.* n’est installée. 3.1.1 est le runtime le plus élevé installé. Un message d’erreur s’affiche.
  • ✔️ 5.0 est spécifié. Aucune version 5.0.* n’est installée. 5.1.0 est la version runtime la plus élevée installée. 5.1.0 est utilisé.
  • ❌ 3.0 est spécifié. Aucune version 3.x n’est installée. 5.0.0 est le runtime le plus élevé installé. Un message d’erreur s’affiche.

La mise à jour de version mineure a un impact secondaire qui peut affecter les utilisateurs finaux. Considérez le scénario suivant :

  1. L’application spécifie que la version 5.0 est requise.
  2. Lors de l’exécution, la version 5.0.* n’est pas installée. Toutefois, la version 5.1.0 est. La version 5.1.0 est utilisée.
  3. Plus tard, l’utilisateur installe 5.0.3 et exécute à nouveau l’application, 5.0.3 est maintenant utilisé.

Il est possible que 5.0.3 et 5.1.0 se comportent différemment, en particulier pour les scénarios tels que la sérialisation des données binaires.

Contrôler le comportement de la restauration par progression

Avant de remplacer le comportement de restauration par progression par défaut, familiarisez-vous avec le niveau de compatibilité du runtime .NET.

Le comportement d'avancement d'une application peut être configuré de quatre façons différentes :

  1. Paramètre du niveau projet en configurant la propriété <RollForward> :

    <PropertyGroup>
  <RollForward>LatestMinor</RollForward>
</PropertyGroup>

  2. Le fichier *.runtimeconfig.json.

    Ce fichier est généré lorsque vous compilez votre application. Si la propriété <RollForward> a été définie dans le projet, elle est reproduite dans le fichier *.runtimeconfig.json comme paramètre de rollForward. Les utilisateurs peuvent modifier ce fichier pour modifier le comportement de votre application.

    {
  "runtimeOptions": {
    "tfm": "net5.0",
    "rollForward": "LatestMinor",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "5.0.0"
    }
  }
}

  3. Propriété dotnet de la --roll-forward <value> commande.

    Lorsque vous exécutez une application, vous pouvez contrôler le comportement de progression par le biais de la ligne de commande :

    dotnet run --roll-forward LatestMinor
dotnet myapp.dll --roll-forward LatestMinor
myapp.exe --roll-forward LatestMinor

  4. Variable d’environnement DOTNET_ROLL_FORWARD.

Préséance

Le comportement de mise à jour est défini par l'ordre suivant lors du lancement de votre application, les éléments avec un numéro plus élevé prenant la priorité sur ceux avec un numéro plus bas :

  1. Tout d’abord, le fichier de configuration *.runtimeconfig.json est évalué.
  2. Ensuite, la variable d’environnement DOTNET_ROLL_FORWARD est considérée comme substituant la vérification précédente.
  3. Enfin, tout paramètre --roll-forward passé à l’application en cours d’exécution remplace tout le reste.

Valeurs

Peu importe comment vous définissez le paramètre de progression, utilisez l’une des valeurs suivantes pour définir le comportement :

Valeur Descriptif
Minor par défaut s’il n’est pas spécifié.
Passez à la prochaine version mineure supérieure disponible (et à la version de correctif la plus élevée disponible dans cette version mineure) si la version mineure demandée est manquante. Si la version mineure demandée est présente, la stratégie LatestPatch est utilisée.
Major Effectuez une mise à niveau vers la prochaine version majeure supérieure disponible (dans sa version mineure la plus basse disponible et son correctif le plus élevé) si la version majeure demandée est manquante. Si la version principale demandée est présente, la stratégie Minor est utilisée.
LatestPatch Transférer vers la version de correctif la plus élevée disponible pour les versions principales et mineures demandées. Cette valeur désactive l'avancement automatique des versions mineures.
LatestMinor Mise à jour vers la version mineure la plus élevée disponible pour la version majeure demandée (et la version patch la plus élevée disponible dans cette version mineure), même si la version mineure demandée est présente.
LatestMajor Mise à jour vers la version majeure la plus récente disponible (et la version mineure et corrective la plus récente disponible au sein de cette version majeure), même si la version majeure demandée est déjà présente.
Disable N’effectuez pas de restauration par progression, mais uniquement à la version spécifiée. Cette stratégie n’est pas recommandée pour une utilisation générale, car elle désactive la possibilité de restaurer vers les derniers correctifs. Cette valeur est uniquement recommandée pour les tests.

Par exemple, supposons qu’une application demande une version8.0.0, tandis que les versions locales disponibles sont 8.2.0, 8.2.3, 8.4.5, 9.0.0, , 9.0.6. 9.7.8 Ensuite, la version résolue est la suivante dans chaque cas :

Valeur Version résolue Version résolue si 8.0.1 était également disponible
Minor 8.2.3 8.0.1
Major 8.2.3 8.0.1
LatestPatch (échec) 8.0.1
LatestMinor 8.4.5 8.4.5
LatestMajor 9.7.8 9.7.8
Disable (échec) (échec)

Les déploiements autonomes incluent le runtime sélectionné

Vous pouvez publier une application sous forme de distribution autonome . Cette approche regroupe le runtime et les bibliothèques .NET avec votre application. Les déploiements autonomes n’ont pas de dépendance sur les environnements d’exécution. La sélection de version du runtime se produit au moment de la publication, et non au moment de l’exécution.

L'événement de restauration qui se produit lorsqu'on publie sélectionne automatiquement la dernière version corrective de la famille d'exécution donnée. Par exemple, dotnet publish sélectionne .NET 5.0.3 s’il s’agit de la dernière version du correctif dans la famille d’exécution .NET 5. L’infrastructure cible (y compris les derniers correctifs de sécurité installés) est empaquetée avec l’application.

Une erreur se produit si la version minimale spécifiée pour une application n’est pas satisfaite. dotnet publish se lie à la dernière version de correctif d'exécution au sein d'une famille de version majeure.mineure spécifiée. dotnet publish ne prend pas en charge la sémantique de restauration par progression de dotnet run. Pour plus d’informations sur les correctifs et les déploiements autonomes, consultez l’article relatif à la sélection de correctif de runtime dans le déploiement d’applications .NET.

Les déploiements autonomes peuvent nécessiter une version de correctif spécifique. Vous pouvez remplacer la version minimale du correctif du runtime (vers des versions ultérieures ou inférieures) dans le fichier projet, comme illustré dans l’exemple suivant :

<PropertyGroup>
  <RuntimeFrameworkVersion>5.0.7</RuntimeFrameworkVersion>
</PropertyGroup>

L’élément RuntimeFrameworkVersion remplace la stratégie de version par défaut. Pour les déploiements autonomes, la RuntimeFrameworkVersion spécifie la version exacte de la plateforme d'exécution. Pour les applications dépendantes du framework, RuntimeFrameworkVersion spécifie la version minimale requise pour le framework du runtime.

Voir aussi

  • Last updated on