Frameworks cibles dans les projets de type kit SDK

Quand vous ciblez un framework dans une application ou une bibliothèque, vous spécifiez l’ensemble d’API que vous souhaitez rendre accessibles à l’application ou à la bibliothèque. Vous spécifiez le framework cible dans votre fichier projet en utilisant un identificateur de framework cible (TFM, target framework moniker).

Une application ou une bibliothèque peut cibler une version de .NET Standard. .NET versions standard représentent des ensembles standardisés d’API dans toutes les implémentations .NET. Par exemple, une bibliothèque peut cibler .NET Standard 1.6 et accéder aux API qui fonctionnent dans .NET Core et .NET Framework à l’aide du même codebase.

Une application ou une bibliothèque peut également cibler une implémentation de .NET spécifique pour accéder aux API spécifiques à l’implémentation. Par exemple, une application qui cible Universal Windows Platform (UWP, uap10.0) a accès aux API qui se compilent pour les appareils qui exécutent Windows 10.

Pour certaines infrastructures cibles, telles que .NET Framework, les API sont définies par les assemblys que l’infrastructure installe sur un système et peuvent inclure des API d’infrastructure d’application (par exemple, ASP.NET).

Pour les frameworks cibles basés sur des packages (par exemple, .NET 5+, .NET Core et .NET Standard), les API sont définies par les packages NuGet inclus dans l’application ou la bibliothèque.

Dernières versions

Le tableau suivant définit les frameworks cibles les plus courants, leur mode de référence et la version de .NET Standard qu'ils implémentent. Ces versions de framework cible sont les dernières versions stables. Les préversions ne sont pas mentionnées. Un moniker de framework target (TFM) est un format de jeton standardisé pour spécifier l’infrastructure cible d’une application ou d’une bibliothèque .NET.

Cadre cible	Dernière version Version stable	Moniker de framework cible	Implémenté version .NET Standard
.NET 10	10	net10.0	2.1
.NET 9	9	net9.0	2.1
.NET 8	8	net8.0	2.1
.NET Standard	2.1	netstandard2.1	N/A
.NET Core	3.1	netcoreapp3.1	2.1
.NET Framework	4.8.1	net481	2.0

Frameworks cibles pris en charge

Un framework cible est généralement référencé par un TFM. Le tableau suivant présente les frameworks cibles pris en charge par le SDK .NET et le client NuGet. Les équivalents sont indiqués entre crochets. Par exemple, win81 est un TFM équivalent de netcore451.

Cadre cible	TFM
.NET 5+ (et .NET Core)	netcoreapp1.0 netcoreapp1.1 netcoreapp2.0 netcoreapp2.1 netcoreapp2.2 netcoreapp3.0 netcoreapp3.1 net5.0* net6.0* net7.0* net8.0* net9.0* net10.0*
.NET Standard	netstandard1.0 netstandard1.1 netstandard1.2 netstandard1.3 netstandard1.4 netstandard1.5 netstandard1.6 netstandard2.0 netstandard2.1
.NET Framework	net11 net20 net35 Net40 net403 net45 net451 net452 net46 net461 net462 net47 net471 net472 Net48 net481
Windows Store	netcore [netcore45] netcore45 [win] [win8] netcore451 [win81]
.NET nanoFramework	netnano1.0
.NET Micro Framework	netmf
Silverlight	sl4 sl5
téléphone Windows	wp [wp7] wp7 wp75 wp8 wp81 wpa81
Universal Windows Platform	uap [uap10.0] uap10.0 [win10] [netcore50]

* .NET 5 et versions ultérieures de TFMs incluent certaines variantes spécifiques au système d’exploitation. Pour plus d’informations, consultez la section suivante, les tfms spécifiques au système d’exploitation.

TfMs spécifiques au système d’exploitation

Les TFMs net8.0, net9.0, et net10.0 incluent des technologies qui fonctionnent sur différentes plateformes. La spécification d’un TFM spécifique à OS rend les API spécifiques à un système d’exploitation disponible pour votre application, par exemple des liaisons Windows Forms ou iOS. Les TFM spécifiques au système d’exploitation héritent également de chaque API disponible pour leur TFM de base, par exemple le TFM net10.0.

Le tableau suivant montre la compatibilité des TFMs .NET 8+.

TFM	Compatible avec
`net8.0`	(version qui suit `net7.0`)
`net8.0-android`	(version qui suit `net7.0-android`)
`net8.0-browser`	Tout ce qui est hérité de `net8.0`
`net8.0-ios`	(version qui suit `net7.0-ios`)
`net8.0-maccatalyst`	(version qui suit `net7.0-maccatalyst`)
`net8.0-macos`	(version qui suit `net7.0-macos`)
`net8.0-tizen`	(version qui suit `net7.0-tizen`)
`net8.0-tvos`	(version qui suit `net7.0-tvos`)
`net8.0-windows`	(version qui suit `net7.0-windows`)
`net9.0`	(version qui suit `net8.0`)
`net9.0-android`	(version qui suit `net8.0-android`)
`net9.0-browser`	(version qui suit `net8.0-browser`)
`net9.0-ios`	(version qui suit `net8.0-ios`)
`net9.0-maccatalyst`	(version qui suit `net8.0-maccatalyst`)
`net9.0-macos`	(version qui suit `net8.0-macos`)
`net9.0-tizen`	(version qui suit `net8.0-tizen`)
`net9.0-tvos`	(version qui suit `net8.0-tvos`)
`net9.0-windows`	(version qui suit `net8.0-windows`)
`net10.0`	(version qui suit `net9.0`)
`net10.0-android`	(version qui suit `net9.0-android`)
`net10.0-browser`	(version qui suit `net9.0-browser`)
`net10.0-ios`	(version qui suit `net9.0-ios`)
`net10.0-maccatalyst`	(version qui suit `net9.0-maccatalyst`)
`net10.0-macos`	(version qui suit `net9.0-macos`)
`net10.0-tizen`	(version qui suit `net9.0-tizen`)
`net10.0-tvos`	(version qui suit `net9.0-tvos`)
`net10.0-windows`	(version qui suit `net9.0-windows`)

Pour rendre votre application portable entre différentes plateformes tout en gardant l’accès à des API spécifiques au système d’exploitation, vous pouvez cibler plusieurs TFM spécifiques au système d’exploitation et ajouter des protections de plateforme aux appels d’API spécifiques au système d’exploitation en utilisant des directives de préprocesseur #if. Pour obtenir la liste des symboles disponibles, consultez Symboles de préprocesseur.

Cibles suggérées

Utilisez ces instructions pour déterminer le TFM à utiliser dans votre application :

Les applications portables sur plusieurs plateformes doivent cibler un TFM de base, par exemple net10.0. Cela inclut la plupart des bibliothèques, mais également ASP.NET Core et Entity Framework.
Les bibliothèques spécifiques à la plateforme doivent cibler des saveurs spécifiques à la plateforme. Par exemple, les projets WinForms et WPF doivent cibler net10.0-windows.
Les modèles d’application multiplateforme (par exemple, ASP.NET Core) doivent au moins cibler le TFM de base, par exemple, net10.0, mais peuvent également cibler des versions supplémentaires spécifiques à la plateforme pour éclairer davantage d’API ou de fonctionnalités.

Version de système d’exploitation dans les TFM

Si vous le souhaitez, vous pouvez également spécifier une version de système d’exploitation à la fin d’un TFM spécifique au système d’exploitation, par exemple net8.0-ios17.2. La version indique les API disponibles pour votre application ou bibliothèque. Il ne contrôle pas la version du système d’exploitation prise en charge par votre application ou bibliothèque au moment de l’exécution. Elle est utilisée pour sélectionner les assemblies de référence contre lesquels votre projet est compilé, ainsi que pour sélectionner des ressources à partir des packages NuGet. Considérez cette version comme étant la « version de plateforme » ou la « version de l’API du système d’exploitation » pour la désambiguer de la version du système d’exploitation runtime.

Le sdk .NET est conçu pour pouvoir prendre en charge les API nouvellement publiées pour une plateforme individuelle sans nouvelle version du TFM de base. Cela vous permet d’accéder à des fonctionnalités spécifiques à la plateforme sans attendre une version majeure de .NET. Vous pouvez accéder à ces API récemment publiées en incrémentant la version de plateforme dans le TFM. Par exemple, si la plateforme Android a ajouté des API de niveau 34 dans une mise à jour .NET sdk 8.0.x, vous pouvez y accéder à l’aide du TFM net8.0-android34.0.

Quand un TFM spécifique au système d’exploitation ne spécifie pas explicitement la version de plateforme, il a une valeur implicite qui peut être déduite du nom de la plateforme et du TFM de base. Par exemple, la version de plateforme par défaut pour Android dans .NET 9 est 35.0, ce qui signifie que net9.0-android est abrégée pour le TFM canonique net9.0-android35.0. Le formulaire abrégé est destiné à être utilisé uniquement dans les fichiers projet et est étendu au formulaire canonique par les cibles MSBuild du KIT de développement logiciel (SDK) .NET avant d'être transmis à d'autres outils, tels que NuGet.

Le tableau suivant montre la version cible par défaut de la plateforme (TPV) pour Android et iOS pour chaque version .NET. Si vous souhaitez utiliser les liaisons les plus récentes, utilisez la valeur par défaut (autrement dit, ne spécifiez pas de version du système d’exploitation).

version .NET	Android	Ios
.NET 8	34,0	17.2
.NET 9	35,0	18,0
.NET 10	36.0	18,7

À compter de .NET 9, lorsque les versions de service introduisent la prise en charge d’une version TPV ultérieure (qui aura toujours la même major numéro de version que lorsque la version de .NET a été initialement publiée), le premier TPV pris en charge pour cette version .NET reste pris en charge. Par exemple, pour .NET 9, la version iOS la plus ancienne prise en charge, 18.0, reste prise en charge, même lorsqu’une version de service ajoute la prise en charge de la dernière version d’iOS 18.x. Si vous devez utiliser les liaisons les plus anciennes pour une version .NET, utilisez un numéro de version de système d’exploitation spécifique dans votre TFM.

Remarque

Sur les plateformes Apple (iOS, macOS, tvOS et Mac Catalyst) dans .NET 8 et versions antérieures, le TPV par défaut est la dernière version prise en charge dans la charge de travail actuellement installée. Cela signifie que la mise à jour de la charge de travail iOS dans .NET 8, par exemple, peut entraîner un TPV par défaut plus élevé, si la prise en charge d’une nouvelle version d’iOS a été ajoutée dans cette charge de travail. Dans le tableau précédent, le TPV par défaut est celui de la première version de la version .NET indiquée.

Depuis .NET 9, ce comportement spécial s’applique uniquement aux projets executable. Le TPV par défaut pour les projets de bibliothèque reste désormais le même pour l’intégralité d’une version majeure de .NET, comme toutes les autres plateformes.

Priorité

Si votre application fait référence à un package qui a plusieurs ressources pour différentes TFMs, les ressources plus proches dans le numéro de version sont préférées. Par exemple, si votre application cible net9.0-ios et que le package propose des ressources pour net9.0 et net8.0-ios, les ressources net9.0 sont utilisées. Pour obtenir plus d’informations, consultez Priorités.

Prise en charge de versions de système d’exploitation antérieures

Bien qu’une application ou une bibliothèque spécifique à la plateforme soit compilée avec des API d’une version spécifique de ce système d’exploitation, vous pouvez la rendre compatible avec des versions antérieures du système d’exploitation en ajoutant la propriété SupportedOSPlatformVersion à votre fichier projet. La propriété SupportedOSPlatformVersion indique la version minimale du système d’exploitation requise pour exécuter votre application ou bibliothèque. Si vous ne spécifiez pas explicitement cette version minimale du système d’exploitation runtime dans le projet, elle est par défaut la version de la plateforme à partir du TFM.

Pour que votre application s’exécute correctement sur une version antérieure du système d’exploitation, tout appel à des API qui n’existent pas sur cette version du système d’exploitation est impossible. Toutefois, vous pouvez ajouter des protections aux appels à des API plus récentes pour qu’elles soient appelées uniquement en cas d’exécution sur une version du système d’exploitation qui les prend en charge. Ce modèle vous permet de concevoir votre application ou bibliothèque pour qu’elle prenne en charge une exécution sur des versions antérieures du système d’exploitation tout en tirant parti des fonctionnalités du système d’exploitation plus récent en cas d’exécution sur des versions plus récentes du système d’exploitation.

La valeur SupportedOSPlatformVersion (explicite ou par défaut) est utilisée par l’analyseur de compatibilité de plateforme, qui détecte les appels non protégés aux API plus récentes et les signale. Elle est inscrite dans l’assembly compilé du projet comme attribut d’assembly UnsupportedOSPlatformAttribute pour que l’analyseur de compatibilité de plateforme puisse détecter les appels non protégés aux API de cet assembly à partir de projets avec une valeur SupportedOSPlatformVersion inférieure. Sur certaines plateformes, la valeur SupportedOSPlatformVersion affecte les processus d’empaquetage et de génération d’applications spécifiques à la plateforme, ce qui est décrit dans la documentation de ces plateformes.

L’exemple suivant est un extrait d’un fichier projet qui utilise les TargetFramework propriétés ET SupportedOSPlatformVersion MSBuild pour spécifier que l’application ou la bibliothèque a accès aux API iOS 15.0, mais prend en charge l’exécution sur iOS 13.0 et versions ultérieures :

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0-ios15.0</TargetFramework>
    <SupportedOSPlatformVersion>13.0</SupportedOSPlatformVersion>
  </PropertyGroup>
  ...

</Project>

Comment spécifier un framework cible

Les frameworks cibles sont spécifiés dans un fichier projet. Quand vous spécifiez un seul framework cible, utilisez l’élément TargetFramework. Le fichier projet d’application console suivante montre comment cibler .NET 10 :

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
  </PropertyGroup>

</Project>

Lorsque vous spécifiez plusieurs plates-formes cibles, vous pouvez référencer les assemblies de manière conditionnelle pour chaque plate-forme cible. Dans votre code, vous pouvez effectuer une compilation conditionnelle par rapport à ces assemblys en utilisant des symboles de préprocesseur avec une logique if-then-else.

Le projet de bibliothèque suivant cible les API de .NET Standard (netstandard1.4) et .NET Framework (net40 et net45). Utilisez l’élément pluriel TargetFrameworks avec plusieurs frameworks cibles. Les attributs Condition incluent des packages spécifiques à l’implémentation lorsque la bibliothèque est compilée pour les deux tfms .NET Framework :

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>netstandard1.4;net40;net45</TargetFrameworks>
  </PropertyGroup>

  <!-- Conditionally obtain references for the .NET Framework 4.0 target -->
  <ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
    <Reference Include="System.Net" />
  </ItemGroup>

  <!-- Conditionally obtain references for the .NET Framework 4.5 target -->
  <ItemGroup Condition=" '$(TargetFramework)' == 'net45' ">
    <Reference Include="System.Net.Http" />
    <Reference Include="System.Threading.Tasks" />
  </ItemGroup>

</Project>

Au sein de votre application ou bibliothèque, vous écrivez du code conditionnel avec des directives de préprocesseur à compiler pour chaque framework cible :

public class MyClass
{
    static void Main()
    {
#if NET40
        Console.WriteLine("Target framework: .NET Framework 4.0");
#elif NET45
        Console.WriteLine("Target framework: .NET Framework 4.5");
#else
        Console.WriteLine("Target framework: .NET Standard 1.4");
#endif
    }
}

Les valeurs TargetFramework sont des alias

La valeur de la propriété TargetFramework (par exemple, net10.0) est un nom convivial , un alias, que le KIT de développement logiciel (SDK) .NET traduit en propriétés moniker canoniques. Plus précisément, le SDK définit les propriétés suivantes à partir de la TargetFramework valeur :

TargetFrameworkMoniker (par exemple, .NETCoreApp,Version=v10.0)
TargetFrameworkIdentifier (par exemple, .NETCoreApp)
TargetFrameworkVersion (par exemple, v10.0)
TargetPlatformMoniker, TargetPlatformIdentifieret TargetPlatformVersion (lors du ciblage d’une plateforme spécifique)

NuGet et le Kit de développement logiciel (SDK) .NET utilisent ces propriétés moniker, et non pas la chaîne TargetFramework, pour les vérifications de compatibilité des packages et la logique de génération. Cette traduction se produit déjà pour les tfms spécifiques au système d’exploitation. Par exemple, net10.0-windows se traduit par TargetFrameworkMoniker = .NETCoreApp,Version=v10.0 et TargetPlatformMoniker = Windows,Version=7.0.

Étant donné que l’alias n’est qu’un nom, la TargetFramework valeur peut être n’importe quelle chaîne alphanumérique, tant que les propriétés de moniker correspondantes sont définies correctement. Le fichier projet suivant utilise un alias personnalisé nommé banana et définit explicitement les propriétés de moniker afin que le projet génère et restaure pour .NET 10.0 :

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>banana</TargetFramework>
  </PropertyGroup>

  <PropertyGroup Condition=" '$(TargetFramework)' == 'banana' ">
    <TargetFrameworkIdentifier>.NETCoreApp</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v10.0</TargetFrameworkVersion>
    <TargetFrameworkMoniker>.NETCoreApp,Version=v10.0</TargetFrameworkMoniker>
  </PropertyGroup>
</Project>

Pour plus d’informations sur ces propriétés, consultez la référence de propriété MSBuild TargetFramework .

Symboles de préprocesseur

Le système de génération tient compte des symboles de préprocesseur qui représentent les frameworks cibles indiqués dans le tableau Versions de framework cible prises en charge quand vous utilisez des projets de type SDK. Pour convertir un .NET Standard, .NET Core ou .NET 5+ TFM en symbole de préprocesseur, remplacez les points et les traits d’union par un trait de soulignement et modifiez les lettres minuscules en majuscules (par exemple, le symbole de netstandard2.0 est NETSTANDARD2_0).

Vous pouvez désactiver la génération de ces symboles avec la propriété DisableImplicitFrameworkDefines. Pour plus d’informations sur cette propriété, consultez DisableImplicitFrameworkDefines.

La liste complète des symboles de préprocesseur pour .NET frameworks cibles est la suivante :

Versions cibles de .NET Framework	symboles	Symboles supplémentaires (disponible dans les sdk .NET 5+ )	Symboles de plateforme (disponibles uniquement lorsque vous spécifiez un TFM spécifique au système d’exploitation)
.NET Framework	`NETFRAMEWORK`, `NET481`, `NET48`, `NET472`, `NET471`, `NET47`, `NET462`, `NET461`, `NET46`, `NET452`, `NET451`, `NET45`, `NET40`, `NET35`, `NET20`	`NET48_OR_GREATER`, `NET472_OR_GREATER`, `NET471_OR_GREATER`, `NET47_OR_GREATER`, `NET462_OR_GREATER`, `NET461_OR_GREATER`, `NET46_OR_GREATER`, `NET452_OR_GREATER`, `NET451_OR_GREATER`, `NET45_OR_GREATER`, `NET40_OR_GREATER`, `NET35_OR_GREATER`, `NET20_OR_GREATER`
.NET Standard	`NETSTANDARD`, `NETSTANDARD2_1`, `NETSTANDARD2_0`, `NETSTANDARD1_6`, `NETSTANDARD1_5`, `NETSTANDARD1_4`, `NETSTANDARD1_3`, `NETSTANDARD1_2`, `NETSTANDARD1_1`, `NETSTANDARD1_0`	`NETSTANDARD2_1_OR_GREATER`, `NETSTANDARD2_0_OR_GREATER`, `NETSTANDARD1_6_OR_GREATER`, `NETSTANDARD1_5_OR_GREATER`, `NETSTANDARD1_4_OR_GREATER`, `NETSTANDARD1_3_OR_GREATER`, `NETSTANDARD1_2_OR_GREATER`, `NETSTANDARD1_1_OR_GREATER`, `NETSTANDARD1_0_OR_GREATER`
.NET 5+ (et .NET Core)	`NET`, `NET10_0`, `NET9_0`, `NET8_0`, `NET7_0`, `NET6_0`, `NET5_0`, `NETCOREAPP`, `NETCOREAPP3_1`, `NETCOREAPP3_0`, `NETCOREAPP2_2`, `NETCOREAPP2_1`, `NETCOREAPP2_0`, `NETCOREAPP1_1`, `NETCOREAPP1_0`	`NET10_0_OR_GREATER`, `NET9_0_OR_GREATER`, `NET8_0_OR_GREATER`, `NET7_0_OR_GREATER`, `NET6_0_OR_GREATER`, `NET5_0_OR_GREATER`, `NETCOREAPP3_1_OR_GREATER`, `NETCOREAPP3_0_OR_GREATER`, `NETCOREAPP2_2_OR_GREATER`, `NETCOREAPP2_1_OR_GREATER`, `NETCOREAPP2_0_OR_GREATER`, `NETCOREAPP1_1_OR_GREATER`, `NETCOREAPP1_0_OR_GREATER`	`ANDROID`, `BROWSER`, `IOS`, `MACCATALYST`, `MACOS`, `TVOS`, `WINDOWS` `[OS][version]` (par exemple, `IOS15_1`), `[OS][version]_OR_GREATER` (par exemple `IOS15_1_OR_GREATER`)

Remarque

Les symboles sans version sont définis indépendamment de la version que vous ciblez.
Les symboles spécifiques à la version sont définis uniquement pour la version que vous ciblez.
Les symboles <framework>_OR_GREATER sont définis pour la version que vous ciblez et toutes les versions antérieures. Par exemple, si vous ciblez .NET Framework 2.0, les symboles suivants sont définis : NET20, NET20_OR_GREATER, NET11_OR_GREATER et NET10_OR_GREATER.
Les symboles NETSTANDARD<x>_<y>_OR_GREATER sont définis uniquement pour les cibles standard .NET, et non pour les cibles qui implémentent .NET Standard, telles que .NET Core et .NET Framework.
Ils sont différents des monikers de framework cible utilisés par la propriété MSBuild TargetFramework et NuGet.

Frameworks cibles dépréciés

Les frameworks cibles suivants sont obsolètes. Les packages qui ciblent ces frameworks cibles doivent migrer vers les versions de remplacement indiquées.

TFM déprécié	Remplacement
aspnet50 aspnetcore50 dnxcore50 dnx dnx45 dnx451 dnx452	netcoreapp
dotnet dotnet50 dotnet51 dotnet52 dotnet53 dotnet54 dotnet55 dotnet56	netstandard
netcore50	uap10.0
gagner	netcore45
Windows 8	netcore45
win81	netcore451
Windows 10	uap10.0
winrt	netcore45

Voir aussi

noms de framework cible dans .NET 5
.NET Standard
.NET gestion des versions
Informations sur la sortie de Windows 11

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-04-17