Frameworks cibles

NuGet utilise des références de framework cible à divers endroits pour identifier et isoler spécifiquement les composants dépendants de l’infrastructure d’un package :

• fichier projet : pour les projets de style SDK, .csproj contient les références de framework cible.
• Manifeste .nuspec : un package peut indiquer des packages distincts à inclure dans un projet en fonction du framework cible du projet.
• Nom du dossier .nupkg : les dossiers à l’intérieur du dossier d’un lib package peuvent être nommés en fonction du framework cible, chacun contenant les DLL et d’autres contenus appropriés à cette infrastructure.
• packages.config: l’attribut targetframework d’une dépendance spécifie la variante d’un package à installer.

Pour obtenir la liste canonique de tous les frameworks cibles pris en charge et leur syntaxe TFM, consultez Les frameworks cibles dans les projets de style SDK.

Les valeurs TargetFramework sont des alias

La TargetFramework propriété d’un fichier projet est un nom convivial , un alias, qui est traduit en une identité de framework canonique. Le Kit de développement logiciel (SDK) .NET effectue cette traduction en définissant le TargetFrameworkMoniker (TFM) et, le cas échéant, les TargetPlatformMoniker propriétés.

Par exemple, lorsque vous écrivez <TargetFramework>net10.0-windows</TargetFramework>, le Kit de développement logiciel (SDK) .NET le traduit en :

• TargetFrameworkMoniker = .NETCoreApp,Version=v10.0
• TargetPlatformMoniker = Windows,Version=7.0

NuGet utilise ces propriétés moniker, et non la TargetFramework chaîne, pour les vérifications de compatibilité des packages. Cela signifie que la TargetFramework valeur elle-même peut être n’importe quelle chaîne, tant que les propriétés de moniker sont définies correctement. Par exemple, le projet suivant est valide :

<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>

Ce projet restaure et génère pour .NET 10.0, même si la TargetFramework valeur est banana. Le Kit de développement logiciel (SDK) .NET s’appuie déjà sur ce mécanisme d’alias pour les tfMs spécifiques au système d’exploitation et net8.0-iosnet8.0-android, où le TFM court est traduit en moniker complet avec des informations de plateforme.

Ciblage multiple avec des frameworks en double

À compter de NuGet 7.6 / .NET SDK 10.0.300, plusieurs TargetFrameworks alias peuvent être résolus dans le même framework efficace. Cela permet des scénarios tels que les builds multi-RID et le ciblage d’extension multiversion. Pour plus d’informations sur l’utilisation de la restauration, du pack, du verrouillage des fichiers et des références de projet, consultez Ciblage de plusieurs frameworks.

Frameworks pris en charge

Un framework est généralement référencé par un moniker de framework cible court ou TFM. Dans .NET Standard, il est également généralisé à TxM pour permettre une référence unique à plusieurs frameworks.

Les clients NuGet prennent en charge les frameworks dans le tableau ci-dessous. Les équivalents sont affichés entre crochets []. Notez que certains outils, tels que dotnet, peuvent utiliser des variantes de tfms canoniques dans certains fichiers. Par exemple, dotnet pack les utilisations .NETCoreApp2.0 dans un .nuspec fichier plutôt que netcoreapp2.0dans . Les différents outils clients NuGet gèrent ces variantes correctement, mais vous devez toujours utiliser des tfms canoniques lors de la modification des fichiers directement.

Infrastructures déconseillées

Les infrastructures suivantes sont déconseillées. Les packages ciblant ces frameworks doivent migrer vers les remplacements indiqués.

Priorité

Un certain nombre de frameworks sont liés et compatibles les uns avec les autres, mais pas nécessairement équivalents :

.NET Standard

.NET Standard simplifie les références entre les frameworks compatibles binaires, ce qui permet à un framework cible unique de référencer une combinaison d’autres. (Pour plus d’informations, consultez .NET Primer.)

L’outil NuGet Get Nearest Framework simule ce que NuGet utilise pour sélectionner une infrastructure parmi de nombreuses ressources d’infrastructure disponibles dans un package basé sur l’infrastructure du projet.

La dotnet série de monikers doit être utilisée dans NuGet 3.3 et versions antérieures ; la netstandard syntaxe de moniker doit être utilisée dans la version 3.4 et ultérieure.

Bibliothèques de classes portables

Pour définir une infrastructure cible qui fait référence à plusieurs frameworks cibles enfants, le portable mot clé utilisé pour préfixer la liste des frameworks référencés. Évitez d’inclure artificiellement des infrastructures supplémentaires qui ne sont pas directement compilées, car elles peuvent entraîner des effets secondaires inattendus dans ces infrastructures.

Les infrastructures supplémentaires définies par des tiers fournissent une compatibilité avec d’autres environnements accessibles de cette façon. En outre, il existe des numéros de profil abrégés qui sont disponibles pour référencer ces combinaisons de frameworks connexes, Profile#mais il n’est pas recommandé d’utiliser ces nombres car il réduit la lisibilité des dossiers et .nuspec.

En outre, les packages NuGet ciblant Xamarin peuvent utiliser des frameworks Xamarin supplémentaires :