Partage via

.NET Standard

.NET Standard est une spécification formelle des API .NET disponibles sur plusieurs implémentations .NET. La motivation de .NET Standard était d’établir une plus grande uniformité dans l’écosystème .NET. .NET 5 et versions ultérieures adoptent une approche différente pour établir l’uniformité qui élimine la nécessité de .NET Standard dans la plupart des scénarios. Toutefois, si vous souhaitez partager du code entre .NET Framework et toute autre implémentation de .NET, telle que .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 les 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 .NET Standard

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

Le ciblage d’une version supérieure de .NET Standard permet à une bibliothèque d’utiliser davantage d’API, mais cela signifie qu’elle ne peut être utilisée que 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 .NET version Standard

  • 1.0
  • 1.1
  • 1.2
  • 1.3
  • 1.4
  • 1.5
  • 1.6
  • 2.0
  • 2.1

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

implémentation de .NET Support de 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, 9.0, 10.0
Framework .NET 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, À déterminer
Unité 2018.1

Pour plus d’informations, consultez .NET Standard 1.0. Pour obtenir une table interactive, consultez .NET versions standard.

Quelle version .NET Standard à cibler

Si vous ciblez .NET Standard, 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 doivent pas avoir besoin d'API en dehors de .NET Standard 2.0 et .NET Framework ne prend pas en charge .NET Standard 2.1. .NET Standard 2.0 est pris en charge par toutes les plateformes modernes et est la méthode recommandée pour prendre en charge plusieurs plateformes avec une seule cible.

Si vous devez prendre en charge .NET Standard 1.x, nous vous recommandons de également cibler .NET Standard 2.0. .NET Standard 1.x est distribué sous la forme d’un ensemble granulaire de packages NuGet, ce qui crée un graphique de dépendances de package volumineux et entraîne un grand nombre de packages téléchargés lors de la génération du projet. Pour plus d’informations, consultez Cross-platform targeting et .NET 5+ et .NET Standard plus loin dans cet article.

Remarque

À compter de .NET 9, un avertissement de build est émis si votre projet cible .NET Standard 1.x. Pour plus d’informations, consultez Avertissement émis pour les cibles .NET Standard 1.x.

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

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

  • Additif : les versions .NET Standard sont des cercles concentriques : les versions supérieures incorporent toutes les API des versions précédentes. Il n’y a pas de modifications majeures entre les versions.
  • Immuables : une fois publiées, les versions .NET Standard sont figées.

Il n’y aura aucune nouvelle version .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 .NET Standard est un ensemble standardisé d’API. La spécification est conservée par .NET implémenteurs, notamment 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 (maintenant archivé) définit les API .NET Standard.

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

Un composant donné, comme , décrit :

  • Partie de .NET Standard (seulement sa portée).
  • 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).

  • Liste des API au format Markdown.
  • Assemblys de référence, distribués comme packages NuGet et référencés par le métapackage NETStandard.Library.

Représentation des paquets

Le véhicule de distribution principal des assemblys de référence .NET Standard est des packages NuGet. Les implémentations sont fournies de différentes manières, appropriées pour chaque implémentation .NET.

Les packages NuGet ciblent un ou plusieurs frameworks. .NET packages Standard ciblent l’infrastructure « .NET Standard ». Vous pouvez cibler l’infrastructure .NET Standard avec l’aide du moniker compact de l'infrastructure cible (TFM), par exemple, . Les bibliothèques destinées à s’exécuter sur plusieurs implémentations de .NET doivent cibler l’infrastructure .NET Standard. Pour le plus large ensemble d’API, 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 fait référence à l’ensemble complet de packages NuGet qui définissent .NET Standard. La méthode la plus courante pour cibler consiste à référencer ce métapackage. Il décrit et fournit l’accès aux bibliothèques ~40 .NET et aux API associées qui définissent .NET Standard. Vous pouvez référencer d’autres packages qui ciblent 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 pas spécifique à une implémentation .NET, ni ne correspond au schéma de contrôle de version de l’une de ces implémentations.

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

Cible .NET Standard

Vous pouvez créer des bibliothèques standard .NET à l’aide d’une combinaison de l’infrastructure netstandard et du métapackage NETStandard.Library.

mode de compatibilité .NET Framework

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

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

bibliothèques standard .NET et Visual Studio

Pour générer .NET bibliothèques Standard dans Visual Studio, vérifiez que vous avez Visual Studio 2019 ou version ultérieure ou Visual Studio 2017 version 15.3 ou ultérieure installée sur Windows.

Si vous n’avez besoin que d’utiliser .NET bibliothèques 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 NuGet téléchargés.

.NET 5+ et .NET Standard

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

  • net10.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.

  • net10.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 qui fait référence.

Quand cibler par rapport à

Pour le code existant qui cible .NET Standard 2.0 ou version ultérieure, il n'est pas nécessaire de modifier le TFM en net8.0 ou un TFM ultérieur. .NET 8, .NET 9 et .NET 10 implémentent .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 langage ou d’API. Par exemple, pour utiliser C# 9, vous devez cibler .NET 5 ou une version ultérieure. Vous pouvez cibler plusieurs versions de .NET et .NET Standard pour accéder aux fonctionnalités plus récentes tout en permettant à votre bibliothèque d'être disponible pour d'autres implémentations de .NET.

Remarque

Si votre projet cible .NET Standard 1.x, nous vous recommandons de le recibler pour .NET Standard 2.0 ou .NET 8+. Pour plus d’informations, consultez Avertissement émis pour les cibles .NET Standard 1.x.

Voici quelques instructions pour le 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 . Par souci 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 est la dernière version prise en charge par .NET Framework, ce qui donne une bonne portée avec un ensemble de fonctionnalités assez volumineux. Nous vous déconseillons de cibler .NET Standard 1.x, car vous limitez l'ensemble de fonctionnalités disponibles pour une augmentation minimale de la portée.

    Si vous n'avez pas besoin de prendre en charge .NET Framework, vous pouvez cibler .NET Standard 2.1 ou .NET 10. Nous vous recommandons d’ignorer .NET Standard 2.1 et de passer directement à .NET 10. Les bibliothèques les plus couramment utilisées sont compatibles avec plusieurs cibles pour .NET Standard 2.0 et .NET 5+. La prise en charge de .NET Standard 2.0 vous donne la plus grande portée, tout en prenant en charge .NET 5+ garantit que vous pouvez tirer parti des dernières fonctionnalités de plateforme pour les clients déjà sur .NET 5+.

problèmes .NET Standard

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

  • Lenteur dans l’ajout de nouvelles API

    .NET Standard a été créé en tant qu’ensemble d’API que toutes les implémentations .NET devrez prendre en charge, il y a donc eu un processus de révision des propositions pour ajouter de nouvelles API. L’objectif était de normaliser uniquement les API qui pourraient être implémentées dans toutes les plateformes actuelles et futures .NET. 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 attendez encore plus longtemps que la nouvelle version de .NET Standard soit largement prise en charge.

    Solution dans .NET 5+ : Lorsqu'une fonctionnalité est implémentée, elle est déjà disponible pour chaque application et bibliothèque .NET 5+, car la base de code est partagée. Et comme il n'existe aucune différence entre la spécification de l'API et son implémentation, vous pouvez tirer parti de 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 aucune séparation entre une spécification d'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 : 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 . 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. Aucune table de numéros de version équivalentes, comme celle pour .NET Standard, n’est nécessaire.

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

    .NET Standard expose les 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 obtenez des erreurs d’exécution.

    Solution dans .NET 5+ : Les sdk .NET 5+ incluent des analyseurs de code 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 obsolète

.NET Standard est toujours nécessaire pour les bibliothèques qui peuvent être utilisées par plusieurs implémentations .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 et .NET Core 3.x.

Voir aussi

  • Last updated on