.NET Standard

  • Article

.NET Standard est une spécification officielle des API .NET qui sont disponibles sur plusieurs implémentations de .NET. La motivation derrière .NET Standard consistait à établir une meilleure uniformité dans l’écosystème .NET. .NET 5 et les versions ultérieures adoptent une approche différente pour établir l’uniformité, qui élimine le besoin de .NET Standard dans la plupart des scénarios. Cependant, si vous voulez partager du code entre .NET Framework et n’importe quelle autre implémentation de .NET, comme .NET Core, votre bibliothèque doit cibler .NET Standard 2.0. Aucune nouvelle version de .NET Standard ne sera publiée, mais .NET 5 et toutes les versions ultérieures continueront de prendre en charge .NET Standard 2.1 et versions antérieures.

Pour plus d’informations sur le choix entre .NET 5+ et .NET Standard, consultez .NET 5+ et .NET Standard plus loin dans cet article.

Versions de .NET Standard

.NET Standard est versionné. Chaque nouvelle version ajoute d’autres API. Quand une bibliothèque est créée sur une certaine version de .NET Standard, elle peut s’exécuter sur n’importe quelle implémentation de .NET qui implémente cette version de .NET Standard (ou une version supérieure).

Le ciblage d’une version supérieure de .NET Standard permet à une bibliothèque d’utiliser davantage d’API, mais signifie qu’elle peut être utilisée seulement sur des versions plus récentes de .NET. Le ciblage d’une version inférieure réduit les API disponibles, mais signifie que la bibliothèque peut s’exécuter dans plus d’emplacements.

Sélectionner la version .NET Standard

.NET Standard 1.0 a 7 949 des 37 118 API disponibles.

Implémentation de .NET Prise en charge de la version
.NET et .NET Core 1.0, 1.1, 2.0, 2.1, 2.2, 3.0, 3.1, 5.0, 6.0, 7.0, 8.0
.NET Framework 4.5, 4.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8, 4.8.1
Mono 4.6, 5.4, 6.4
Xamarin.iOS 10.0, 10.14, 12.16
Xamarin.Mac 3.0, 3.8, 5.16
Xamarin.Android 7.0, 8.0, 10.0
Plateforme Windows universelle 8.0, 8.1, 10.0, 10.0.16299, TBD
Unity 2018.1

Pour plus d’informations, consultez .NET Standard 1.0. Pour un tableau interactif, consultez Versions .NET Standard.

Version de .NET Standard à cibler

Nous vous recommandons de cibler .NET Standard 2.0, sauf si vous devez prendre en charge une version antérieure. La plupart des bibliothèques à usage général ne devraient pas avoir besoin d’API en dehors de .NET Standard 2.0. .NET Standard 2.0 est pris en charge par toutes les plateformes modernes et constitue la méthode recommandée pour prendre en charge plusieurs plateformes avec une cible.

Si vous devez prendre en charge .NET Standard 1.x, nous vous recommandons de cibler aussi .NET Standard 2.0. .NET Standard 1.x est distribué sous la forme d’un ensemble précis de packages NuGet, qui crée un grand graphique des dépendances de package et amène les développeurs à télécharger un grand nombre de packages lors de la génération. Pour plus d’informations, consultez Ciblage multiplateforme et .NET 5+ et .NET Standard plus loin dans cet article.

Règles de contrôle de version de .NET standard

Il existe deux règles principales de contrôle de version :

  • Additive : les versions de .NET Standard sont des cercles logiquement concentriques : les versions plus élevées intègrent toutes les API des versions précédentes. Il n’y a pas de ruptures entre les versions.
  • Immuable : une fois livrées, les versions de .NET Standard sont figées.

Il n’y aura pas de nouvelle version de .NET Standard après la version 2.1. Pour plus d’informations, consultez .NET 5+ et .NET Standard plus loin dans cet article.

Caractéristique

La spécification de .NET Standard est un ensemble d’API normalisé. La spécification est gérée par les entités chargées de l’implémentation de .NET, en particulier Microsoft (inclut .NET Framework, .NET Core et Mono) et Unity.

Artefacts officiels

La spécification officielle est un ensemble de fichiers .cs définissant les API qui font partie du standard. Le répertoire ref dans le dépôt dotnet/standard (désormais archivé) définit les API .NET Standard.

Le métapackage NETStandard.Library (source) décrit l’ensemble des bibliothèques qui définissent (en partie) une ou plusieurs versions de .NET Standard.

Un composant donné, comme System.Runtime, décrit :

  • Une partie de .NET Standard (seulement son étendue).
  • Plusieurs versions de .NET Standard, pour cette étendue.

Des artefacts dérivés sont fournis pour une lecture plus pratique et pour activer certains scénarios de développement (par exemple, utilisation d’un compilateur).

Représentation des packages

Les assemblys de référence de .NET Standard sont distribués principalement via les packages NuGet. Les implémentations sont fournies de façons différentes, en fonction de l’implémentation de .NET.

Les packages NuGet ciblent un ou plusieurs frameworks. Les packages .NET Standard ciblent le framework « .NET Standard ». Vous pouvez cibler le .NET Framework Standard avec le Moniker de framework cible compactnetstandard (par exemple netstandard1.4). Les bibliothèques destinées à s’exécuter sur plusieurs implémentations de .NET doivent cibler ce framework. Pour l’ensemble d’API le plus large, ciblez netstandard2.0, car le nombre d’API disponibles a plus que doublé entre .NET Standard 1.6 et 2.0.

Le métapackage NETStandard.Library référence l’ensemble complet des packages NuGet qui définissent .NET Standard. La méthode la plus courante pour cibler netstandard consiste à référencer ce métapackage. Il décrit et donne accès à la quarantaine de bibliothèques .NET et les API associées qui définissent .NET Standard. Vous pouvez référencer d’autres packages qui ciblent netstandard pour avoir accès à d’autres API.

Gestion de version

La spécification n’est pas unique, c’est un ensemble d’API versionné linéairement. La première version de la norme établit un ensemble d’API de référence. Les versions ultérieures ajoutent des API et héritent des API définies par les versions précédentes. Il n’existe pas de disposition permettant de retirer des API du standard.

.NET Standard n’est spécifique à aucune implémentation de .NET et ne correspond pas au schéma de versioning de ces implémentations.

Comme indiqué précédemment, il n’y aura pas de nouvelle version de .NET Standard après la version 2.1.

Cibler .NET Standard

Vous pouvez créer des bibliothèques .NET Standard en combinant le framework netstandard et le métapackage NETStandard.Library.

Mode de compatibilité du .NET Framework

Le mode de compatibilité du .NET Framework a été introduit dans .NET Standard 2.0. Ce mode de compatibilité permet aux projets .NET Standard de référencer des bibliothèques .NET Framework comme si elles étaient compilées pour .NET Standard. Le référencement de bibliothèques .NET Framework ne fonctionne pas pour tous les projets, par exemple pour les bibliothèques qui utilisent des API WPF (Windows Presentation Foundation).

Pour plus d’informations, consultez Mode de compatibilité du .NET Framework.

Bibliothèques .NET Standard et Visual Studio

Pour générer des bibliothèques .NET Standard dans Visual Studio, assurez-vous que Visual Studio 2022, Visual Studio 2019 ou Visual Studio 2017 version 15.3 or une version ultérieure est installé sur Windows, ou que Visual Studio pour Mac version 7.1 ou ultérieure est installé sur macOS.

Si vous devez seulement utiliser les bibliothèques .NET Standard 2.0 dans vos projets, vous pouvez également le faire dans Visual Studio 2015. Cependant, le client NuGet 3.6 ou ultérieur doit être installé. Vous pouvez télécharger le client NuGet pour Visual Studio 2015 à partir de la page Téléchargements NuGet.

.NET 5+ et .NET Standard

.NET 5, .NET 6, .NET 7 et .NET 8 sont des produits uniques avec un ensemble uniforme de fonctionnalités et d’API qui peuvent être utilisées pour les applications de bureau Windows et les applications console multiplateformes, les services cloud et les sites web. Par exemple, les TFM .NET 8 reflètent cette large gamme de scénarios :

  • net8.0

    Ce TFM est destiné au code qui s’exécute partout. À quelques exceptions près, il inclut seulement des technologies qui fonctionnent sur plusieurs plateformes. Pour le code .NET 8, net8.0 remplace à la fois les TFM netcoreapp et netstandard.

  • net8.0-windows

    Il s’agit d’un exemple de TFM spécifique au système d’exploitation qui ajoute des fonctionnalités spécifiques au système d’exploitation à tout ce à quoi net8.0 fait référence.

Quand cibler net8.0 et netstandard

Pour le code existant qui cible netstandard, il n’est pas nécessaire de changer le TFM en net8.0 ou en un TFM ultérieur. .NET 8 implémente .NET Standard 2.1 et versions antérieures. La seule raison de recibler de .NET Standard vers .NET 8+ serait d’accéder à davantage de fonctionnalités d’exécution, de fonctionnalités de langages ou d’API. Par exemple, pour utiliser C# 9, vous devez cibler .NET 5 ou une version ultérieure. Vous pouvez cibler plusieurs fois .NET 8 et .NET Standard pour accéder à des fonctionnalités plus récentes tout en conservant votre bibliothèque disponible pour d’autres implémentations .NET.

Voici quelques conseils relatifs au nouveau code pour .NET 5+ :

  • Composants de l’application

    Si vous utilisez des bibliothèques pour décomposer une application en plusieurs composants, nous vous recommandons de cibler net8.0. Pour des raisons de simplicité, il est préférable de conserver tous les projets qui composent votre application sur la même version de .NET. Vous pouvez alors supposer que les fonctionnalités BCL sont les mêmes partout.

  • Bibliothèques réutilisables

    Si vous créez des bibliothèques réutilisables que vous prévoyez de livrer sur NuGet, réfléchissez au compromis entre l’amplitude et l’ensemble des fonctionnalités disponibles. .NET Standard 2.0 étant la dernière version prise en charge par .NET Framework, il offre une bonne amplitude avec un ensemble de fonctionnalités assez étendu. Nous vous déconseillons de cibler .NET Standard 1.x, car vous limiteriez ainsi l’ensemble des fonctionnalités disponibles pour une augmentation limitée de l’amplitude.

    Si vous n’avez pas besoin de prendre en charge .NET Framework, vous pouvez utiliser .NET Standard 2.1 ou .NET 8. Nous vous recommandons d’ignorer .NET Standard 2.1 et de passer directement à .NET 8. Les bibliothèques les plus couramment utilisées sont multicibles à la fois pour .NET Standard 2.0 et pour .NET 5+. La prise en charge de .NET Standard 2.0 vous offre la meilleure amplitude, tandis que la prise en charge de .NET 5+ vous permet de tirer parti des dernières fonctionnalités de la plateforme pour les clients qui sont déjà sur .NET 5+.

Problèmes liés à .NET Standard

Voici quelques problèmes liés à .NET Standard qui expliquent pourquoi .NET 5 et ses versions ultérieures sont le meilleur moyen de partager du code entre des plateformes et des charges de travail :

  • Lenteur dans l’ajout de nouvelles API

    .NET Standard a été créé pour être un ensemble d’API que toutes les implémentations de .NET allaient devoir prendre en charge : il y avait donc un processus de révision des propositions d’ajout de nouvelles API. L’objectif était de standardiser seulement les API qui pouvaient être implémentées dans toutes les plateformes .NET actuelles et futures. Le résultat a été que si une fonctionnalité était manquante dans une version particulière, vous deviez dans certains cas attendre quelques années avant qu’elle soit ajoutée à une version de .NET Standard. Ensuite, vous deviez attendre encore plus longtemps pour que la nouvelle version de .NET Standard soit largement prise en charge.

    Solution dans .NET 5+ : Quand une fonctionnalité est implémentée, elle est déjà disponible pour chaque bibliothèque et application .NET 5+, car la base de code est partagée. Et comme il n’y a aucune différence entre la spécification de l’API et son implémentation, vous pouvez tirer parti des nouvelles fonctionnalités beaucoup plus rapidement qu’avec .NET Standard.

  • Versioning complexe

    La séparation entre la spécification de l’API et ses implémentations aboutit à un mappage complexe entre les versions des spécifications de l’API et les versions de son implémentation. Cette complexité est évidente dans le tableau figurant plus haut dans cet article et dans les instructions pour l’interpréter.

    Solution dans .NET 5+ : Il n’existe pas de séparation entre la spécification d’une API .NET 5+ et son implémentation. Le résultat est un schéma TFM simplifié. Il y a un préfixe TFM pour toutes les charges de travail : net8.0 est utilisé pour les bibliothèques, les applications console et les applications web. La seule variation est un suffixe qui spécifie les API spécifiques à la plateforme pour une plateforme particulière, comme net8.0-windows. Grâce à cette convention de nommage de TFM, vous pouvez déterminer facilement si une application donnée peut utiliser une bibliothèque donnée. Aucun tableau d’équivalence des numéros de version comme celle de .NET Standard n’est nécessaire.

  • Exceptions non prises en charge par la plateforme au moment de l’exécution

    .NET Standard expose des API spécifiques à la plateforme. Votre code peut se compiler sans erreur et sembler portable sur n’importe quelle plateforme, même s’il n’est en réalité pas portable. Quand il s’exécute sur une plateforme qui n’a pas d’implémentation pour une API donnée, vous recevez des erreurs à l’exécution.

    Solution dans .NET 5+ : Les SDK .NET 5+ incluent des analyseurs de code qui sont activés par défaut. L’analyseur de compatibilité de plateforme détecte l’utilisation non intentionnelle d’API qui ne sont pas prises en charge sur les plateformes sur lesquelles vous envisagez d’exécuter. Pour plus d’informations, consultez Analyseur de compatibilité de plateforme.

.NET Standard non déprécié

.NET Standard est toujours nécessaire pour les bibliothèques qui peuvent être utilisées par plusieurs implémentations de .NET. Nous vous recommandons de cibler .NET Standard dans les scénarios suivants :

  • Utilisez netstandard2.0 pour partager du code entre .NET Framework et toutes les autres implémentations de .NET.
  • Utilisez netstandard2.1 pour partager du code entre Mono, Xamarin et .NET Core 3.x.

Voir aussi