Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Wenn Sie ein Framework in einer App oder Bibliothek als Ziel verwenden, geben Sie mehrere APIs an, die Sie für die App oder Bibliothek verfügbar machen möchten. Das Zielframework wird mithilfe von Zielframeworkmonikern (Target Framework Monikers, TFMs) in Ihrer Projektdatei angegeben.
Eine App oder Bibliothek kann eine Version des .NET Standards als Ziel verwenden. .NET Standard-Versionen stellen standardisierte APIs in allen .NET-Implementierungen dar. Eine Bibliothek kann z.B. NET Standard 1.6 als Ziel verwenden und Zugriff auf APIs erhalten, die sowohl in .NET Core und .NET Framework mit der gleichen Codebasis funktionieren.
Eine App oder Bibliothek kann auch eine spezifische .NET-Implementierung als Ziel verwenden, um Zugriff auf implementierungsspezifische APIs zu erhalten. Beispielsweise hat eine App, die auf die Universelle Windows-Plattform (UWP) abzielt, Zugriff auf APIs, uap10.0die für Geräte kompiliert werden, auf denen Windows 10 ausgeführt wird.
Für einige Zielframeworks (z. B. das .NET Framework) werden die APIs von den Assemblys definiert, die das Framework in einem System installiert. Zu diesen APIs können auch Anwendungsframework-APIs zählen (z. B. ASP.NET).
Für paketbasierte Zielframeworks (z. B. .NET 5 oder höher, .NET Core und .NET Standard) werden die APIs von den NuGet-Paketen definiert, die in der App oder der Bibliothek enthalten sind.
Neueste Versionen
In der folgenden Tabelle wird aufgelistet, wie die häufigsten Zielframeworks lauten, wie auf diese verwiesen wird und welche Version von .NET Standard sie implementieren. Diese Zielframeworkversionen sind die neuesten stabilen Versionen. Vorabversionen werden nicht angezeigt. Ein Zielframeworkmoniker (Target Framework Moniker, TFM) ist ein standardisiertes Tokenformat zum Angeben des Zielframeworks einer .NET-App oder -Bibliothek.
| Zielframework | Neueste Version Stabile Version |
TFM | Implementiert .NET Standard-Version |
|---|---|---|---|
| .NET 9 | 9 | net9.0 | 2.1 |
| .NET 8 | 8 | net8.0 | 2.1 |
| .NET Standard | 2.1 | netstandard2.1 | – |
| .NET Core | 3.1 | netcoreapp3.1 | 2.1 |
| .NET Framework | 4.8.1 | net481 | 2.0 |
Unterstützte Zielframeworks
Auf ein Zielframework wird normalerweise mit einem TFM verwiesen. In der folgenden Tabelle werden die vom .NET SDK und dem NuGet-Client unterstützten Zielframeworks aufgelistet. Äquivalente werden in Klammern angegeben.
win81 ist z.B ein äquivalenter TFM von netcore451.
| Zielframework | TFM |
|---|---|
| .NET 5 oder höher (und .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* |
| .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 |
| Windows Phone | wp [wp7] wp7 wp75 wp8 wp81 wpa81 |
| Universelle Windows-Plattform | uap [uap10.0] uap10.0 [win10] [netcore50] |
* Die TFMs in .NET 5 und höher enthalten einige betriebssystemspezifische Varianten. Weitere Informationen finden Sie im folgenden Abschnitt Betriebssystemspezifische TFMs in .NET 5 oder höher.
Betriebssystemspezifische TFMs in .NET 5 oder höher
Zu den net5.0TFMs net6.0net7.0net8.0net9.0 gehören Technologien, die auf verschiedenen Plattformen funktionieren. Das Angeben eines betriebssystemspezifischen TFM führt dazu, dass APIs für ein Betriebssystem spezifisch sind, das für Ihre App verfügbar ist, z. B. Windows Forms oder iOS-Bindungen. Betriebssystemspezifische TFMs erben auch jede API, die für Ihren Basis-TFM verfügbar ist, z. B. den net9.0-TFM.
Mit .NET 5 wurde der betriebssystemspezifische net5.0-windows-TFM eingeführt, der Windows-spezifische Bindungen für WinForms-, WPF- und UWP-APIs umfasst. .NET 6 und höhere Versionen verfügen über zusätzliche betriebssystemspezifische TFMs, z. B. net6.0-ios.
Die folgende Tabelle zeigt die Kompatibilität der .NET 5-TFMs (oder höher).
| TFM | Kompatibel mit |
|---|---|
net5.0 |
net1..4 (mit NU1701-Warnung) netcoreapp1..3.1 (Warnung bei Verweis auf WinForms oder WPF) netstandard1.. 2.1 |
net5.0-windows |
netcoreapp1..3.1 (plus alles Ererbte von net5.0) |
net6.0 |
(Nachfolgeversion von net5.0) |
net6.0-android |
xamarin.android (und alles andere von net6.0 geerbte) |
net6.0-ios |
Alles geerbt von net6.0 |
net6.0-maccatalyst |
Alles geerbt von net6.0 |
net6.0-macos |
Alles geerbt von net6.0 |
net6.0-tvos |
Alles geerbt von net6.0 |
net6.0-windows |
(Nachfolgeversion von net5.0-windows) |
net7.0 |
(Nachfolgeversion von net6.0) |
net7.0-android |
(Nachfolgeversion von net6.0-android) |
net7.0-ios |
(Nachfolgeversion von net6.0-ios) |
net7.0-maccatalyst |
(Nachfolgeversion von net6.0-maccatalyst) |
net7.0-macos |
(Nachfolgeversion von net6.0-macos) |
net7.0-tizen |
tizen40 (und alles andere von net7.0 geerbte) |
net7.0-tvos |
(Nachfolgeversion von net6.0-tvos) |
net7.0-windows |
(Nachfolgeversion von net6.0-windows) |
net8.0 |
(Nachfolgeversion von net7.0) |
net8.0-android |
(Nachfolgeversion von net7.0-android) |
net8.0-browser |
Alles geerbt von net8.0 |
net8.0-ios |
(Nachfolgeversion von net7.0-ios) |
net8.0-maccatalyst |
(Nachfolgeversion von net7.0-maccatalyst) |
net8.0-macos |
(Nachfolgeversion von net7.0-macos) |
net8.0-tizen |
(Nachfolgeversion von net7.0-tizen) |
net8.0-tvos |
(Nachfolgeversion von net7.0-tvos) |
net8.0-windows |
(Nachfolgeversion von net7.0-windows) |
net9.0 |
(Nachfolgeversion von net8.0) |
net9.0-android |
(Nachfolgeversion von net8.0-android) |
net9.0-browser |
(Nachfolgeversion von net8.0-browser) |
net9.0-ios |
(Nachfolgeversion von net8.0-ios) |
net9.0-maccatalyst |
(Nachfolgeversion von net8.0-maccatalyst) |
net9.0-macos |
(Nachfolgeversion von net8.0-macos) |
net9.0-tizen |
(Nachfolgeversion von net8.0-tizen) |
net9.0-tvos |
(Nachfolgeversion von net8.0-tvos) |
net9.0-windows |
(Nachfolgeversion von net8.0-windows) |
Damit Ihre App auf verschiedenen Plattformen genutzt werden kann, Zugriff auf betriebssystemspezifische APIs aber trotzdem möglich ist, können Sie als Ziel mehrere betriebssystemspezifische TFMs verwenden und Plattformwächter für betriebssystemspezifische API-Aufrufe hinzufügen, indem Sie #if-Präprozessoranweisungen nutzen. Eine Liste der verfügbaren Symbole finden Sie unter Präprozessorsymbole.
Vorgeschlagene Ziele
Verwenden Sie diese Richtlinien, um zu bestimmen, welchen TFM Sie für Ihre App verwenden:
- Apps, die für mehrere Plattformen genutzt werden können, sollten einen Basis-TFM (z. B.
net9.0) als Ziel verwenden. Dazu gehören die meisten Bibliotheken, jedoch auch ASP.NET Core und Entity Framework. - Plattformspezifische Bibliotheken sollten plattformspezifische Varianten als Ziel verwenden. WinForms- und WPF-Projekte sollten beispielsweise
net9.0-windowsals Ziel verwenden. - Plattformübergreifende Anwendungsmodelle (z. B. ASP.NET Core) sollten zumindest auf die Basis-TFM abzielen,
net9.0können aber auch auf zusätzliche plattformspezifische Varianten abzielen, um mehr APIs oder Features zu erhellen.
Betriebssystemversion in TFMs
Sie können am Ende eines betriebssystemspezifischen TFM auch eine optionale Betriebssystemversion angeben, z. B. net6.0-ios15.0. Die Version gibt an, welche APIs für Ihre App oder Bibliothek verfügbar sind. Sie steuert nicht die Betriebssystemversion, die Ihre App oder Bibliothek zur Laufzeit unterstützt. Sie wird verwendet, um die Verweisassemblys auszuwählen, mit denen Ihr Projekt kompiliert wird, und um Ressourcen aus NuGet-Paketen auszuwählen. Stellen Sie sich diese Version als „Plattformversion“ oder „Betriebssystem-API-Version“ vor, um sie von der Betriebssystemversion zur Laufzeit zu unterscheiden.
Das .NET SDK ist so konzipiert, dass es neu veröffentlichte APIs für eine einzelne Plattform ohne eine neue Version des Basis-TFM unterstützen kann. Dadurch können Sie auf plattformspezifische Funktionen zugreifen, ohne auf eine Hauptversion von .NET warten zu müssen. Sie können auf diese neu veröffentlichten APIs zugreifen, indem Sie die Plattformversion im TFM erhöhen. Wenn beispielsweise die Android-Plattform in einem .NET 6.0.x SDK-Update APIs der API-Ebene 32 hinzufügt, können Sie mit dem TFM net6.0-android32.0 auf diese zugreifen.
Wenn ein betriebssystemspezifischer TFM die Plattformversion nicht explizit angibt, verfügt er über einen impliziten Wert, der aus dem Basis-TFM und dem Plattformnamen abgeleitet werden kann. Beispielsweise lautet 35.0die Standardplattformversion für Android in .NET 9 , was bedeutet, dass dies net9.0-android kurz für die kanonische netp.0-android35.0 TFM ist. Die Kurzform ist nur für die Verwendung in Projektdateien vorgesehen und wird durch die MSBuild Ziele des .NET SDK vor der Übergabe an andere Tools wie NuGet auf die kanonische Form erweitert.
Die folgende Tabelle zeigt die Standardmäßige Zielplattformversion (TPV) für jede .NET-Version. Wenn Sie die neuesten Bindungen verwenden möchten, verwenden Sie die Standardeinstellung (d. h. geben Sie keine Betriebssystemversion an).
| .NET-Version | Android | Ios | Mac Catalyst | macOS | tvOS | Tizen | Fenster |
|---|---|---|---|---|---|---|---|
| .NET 8 | 34,0 | 17.2 | 17.2 | 14.2 | 17.1 | 10,0 | 7.0 |
| .NET 9 | 35.0 | 18.0 | 18.0 | 15,0 | 10,0 | 7.0 |
Ab .NET 9 wird die früheste unterstützte TPV-Version für diese .NET-Version weiterhin unterstützt, wenn Dienstversionen unterstützung für eine spätere TPV -Version einführen (die immer die gleiche Hauptversionsnummer aufweist wie bei der ersten Veröffentlichung der .NET-Version). For example, for .NET 9, the earliest supported iOS version, 18.0, will remain supported, even when a service release adds support for the latest iOS 18.x version. Wenn Sie die frühesten Bindungen für eine .NET-Version verwenden müssen, verwenden Sie eine bestimmte Betriebssystemversionsnummer in Ihrer TFM.
Hinweis
Auf Apple-Plattformen (iOS, macOS, tvOS und Mac Catalyst) in .NET 8 und früher ist der Standard-TPV die neueste unterstützte Version im aktuell installierten Workload. Das bedeutet, dass eine Aktualisierung des iOS-Workloads in .NET 8 beispielsweise zu einem höheren Standard-TPV führen kann, wenn in diesem Workload die Unterstützung für eine neue Version von iOS hinzugefügt wurde. In der vorherigen Tabelle ist der Standard-TPV die Version in der ersten Version für die angegebene .NET-Version.
Ab .NET 9 gilt dieses spezielle Verhalten nur für ausführbare Projekte. Der Standard-TPV für Bibliotheksprojekte bleibt jetzt für die gesamte Dauer einer .NET-Hauptversion gleich, wie bei allen anderen Plattformen.
Rangfolge
Wenn Ihre App auf ein Paket verweist, das mehrere Ressourcen für unterschiedliche TFMs enthält, werden die Ressourcen bevorzugt, deren Versionsnummern näher beieinander liegen. Wenn Ihre App beispielsweise net6.0-ios als Ziel hat und das Paket Ressourcen für net6.0 und net5.0-ios bietet, werden die net6.0-Ressourcen verwendet. Weitere Informationen finden Sie unter Rangfolgen.
Unterstützung älterer Betriebssystemversionen
Eine plattformspezifische App oder Bibliothek für APIs wird zwar aus einer bestimmten Version dieses Betriebssystems kompiliert, aber Sie können sie mit früheren Betriebssystemversionen kompatibel machen, indem Sie Ihrer Projektdatei die Eigenschaft SupportedOSPlatformVersion hinzufügen. Die Eigenschaft SupportedOSPlatformVersion gibt die Betriebssystemversion an, die zum Ausführen Ihrer App oder Bibliothek mindestens erforderlich ist. Wenn Sie diese Betriebssystem-Mindestversion, die zur Laufzeit verwendet werden soll, im Projekt nicht explizit angeben, wird standardmäßig die Plattformversion aus dem TFM verwendet.
Damit Ihre App unter einer älteren Betriebssystemversion ordnungsgemäß ausgeführt werden kann, kann sie keine APIs aufrufen, die in dieser Version des Betriebssystems nicht vorhanden sind. Sie können jedoch Wächter für Aufrufe neuerer APIs hinzufügen, sodass die APIs nur aufgerufen werden, wenn sie in einer Version des Betriebssystems ausgeführt werden, die sie unterstützt. Mit diesem Muster können Sie Ihre App oder Bibliothek so entwerfen, dass sie die Ausführung unter älteren Betriebssystemversionen unterstützt und gleichzeitig neuere Betriebssystemfunktionen nutzt, wenn sie unter neueren Betriebssystemversionen ausgeführt wird.
Der SupportedOSPlatformVersion-Wert (egal ob explizit angegeben oder standardmäßig verwendet) wird vom Analysetool für die Plattformkompatibilität verwendet, das unbeaufsichtigte Aufrufe neuerer APIs erkennt und entsprechende Warnungen ausgibt. Sie wird als UnsupportedOSPlatformAttribute-Assemblyattribut in die kompilierte Assembly des Projekts eingebaut, sodass das Analysetool für die Plattformkompatibilität unbeaufsichtigte Aufrufe der APIs dieser Assembly aus Projekten mit einem niedrigeren SupportedOSPlatformVersion-Wert erkennen kann. Auf einigen Plattformen wirkt sich der SupportedOSPlatformVersion-Wert auf plattformspezifische Prozesse für die App-Paketerstellung und -Kompilierung aus, die in der Dokumentation für diese Plattformen behandelt werden.
Hier sehen Sie einen Beispielauszug einer Projektdatei, die die MSBuild-Eigenschaften TargetFramework und SupportedOSPlatformVersion verwendet, um anzugeben, dass die App oder Bibliothek Zugriff auf iOS 15.0-APIs hat, aber die Ausführung unter iOS 13.0 und höher unterstützt:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0-ios15.0</TargetFramework>
<SupportedOSPlatformVersion>13.0</SupportedOSPlatformVersion>
</PropertyGroup>
...
</Project>
Angeben eines Zielframeworks
Zielframeworks werden in einer Projektdatei angegeben. Wenn ein einzelnes Zielframework angegeben wird, verwenden Sie das Element „TargetFramework“. Die folgende Konsolen-App-Projektdatei veranschaulicht, wie .NET 9 als Ziel verwendet wird:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net9.0</TargetFramework>
</PropertyGroup>
</Project>
Wenn Sie mehrere Zielframeworks angeben, können Sie bedingt auf Assemblys für jedes Zielframework verweisen. Sie können in Ihrem Code bedingt mit diesen Assemblys kompilieren, indem Sie die Präprozessorsymbole mit wenn-dann-sonst-Logik (if-then-else) verwenden.
Die folgende Bibliotheksprojektdatei ist auf APIs von .NET Standard (netstandard1.4) und des .NET Framework (net40 und net45) ausgerichtet. Verwenden Sie das Element „TargetFrameworks“ im Plural für mehrere Zielframeworks. Die Condition-Attribute enthalten implementierungsspezifische Pakete, wenn die Bibliothek für die zwei .NET Framework-TFMs kompiliert wird:
<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>
In Ihrer Bibliothek oder App schreiben Sie mithilfe von Präprozessoranweisungen Bedingungscode, um für die verschiedenen Zielframeworks zu kompilieren:
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
}
}
Präprozessorsymbole
Das Buildsystem beachtet Präprozessorsymbole, die Zielframeworks darstellen, die in der Tabelle Unterstützte Zielframeworkversionen aufgelistet sind, wenn Sie Projekte im SDK-Format verwenden. Um einen .NET Standard-, .NET Core- oder .NET 5+-TFM in ein Präprozessorsymbol zu konvertieren, ersetzen Sie Punkte und Bindestriche durch einen Unterstrich, und ändern Sie Klein- in Großbuchstaben (das Symbol für netstandard1.4 ist z. B. NETSTANDARD1_4).
Sie können die Generierung dieser Symbole über die DisableImplicitFrameworkDefines-Eigenschaft deaktivieren. Weitere Informationen zu dieser Eigenschaft finden Sie unter DisableImplicitFrameworkDefines.
Hier finden Sie eine vollständige Liste der Präprozessorsymbole für .NET-Zielframeworks:
| Zielframeworks | Symbole | Zusätzliche Symbole (verfügbar in SDKs für .NET 5 und höher) |
Plattformsymbole (nur verfügbar, wenn Sie einen betriebssystemspezifischen TFM angeben) |
|---|---|---|---|
| .NET Framework |
NETFRAMEWORK, NET481, , NET48, NET472, NET471, NET47NET462NET461NET46NET452NET451NET45NET40NET35NET20 |
NET48_OR_GREATER, NET472_OR_GREATER, , NET471_OR_GREATER, NET47_OR_GREATER, NET462_OR_GREATERNET461_OR_GREATER, NET46_OR_GREATER, , NET452_OR_GREATER, NET451_OR_GREATER, , NET45_OR_GREATERNET40_OR_GREATER, , NET35_OR_GREATERNET20_OR_GREATER |
|
| .NET Standard |
NETSTANDARD, NETSTANDARD2_1, , NETSTANDARD2_0NETSTANDARD1_6, NETSTANDARD1_5, NETSTANDARD1_4, NETSTANDARD1_3, , , NETSTANDARD1_2, , NETSTANDARD1_1NETSTANDARD1_0 |
NETSTANDARD2_1_OR_GREATER, NETSTANDARD2_0_OR_GREATER, , NETSTANDARD1_6_OR_GREATERNETSTANDARD1_5_OR_GREATER, NETSTANDARD1_4_OR_GREATER, NETSTANDARD1_3_OR_GREATER, NETSTANDARD1_2_OR_GREATER, , NETSTANDARD1_1_OR_GREATERNETSTANDARD1_0_OR_GREATER |
|
| .NET 5 oder höher (und .NET Core) |
NET, NET9_0, , NET8_0, NET7_0, NET6_0NET5_0NETCOREAPPNETCOREAPP3_1, , , NETCOREAPP3_0NETCOREAPP2_2NETCOREAPP2_1NETCOREAPP2_0NETCOREAPP1_1NETCOREAPP1_0 |
NET9_0_OR_GREATER, NET8_0_OR_GREATER, , NET7_0_OR_GREATER, NET6_0_OR_GREATER, NET5_0_OR_GREATERNETCOREAPP3_1_OR_GREATER, NETCOREAPP3_0_OR_GREATER, NETCOREAPP2_2_OR_GREATER, , NETCOREAPP2_1_OR_GREATER, NETCOREAPP2_0_OR_GREATER, , NETCOREAPP1_1_OR_GREATERNETCOREAPP1_0_OR_GREATER |
ANDROID, , BROWSERIOS, MACCATALYST, MACOS, TVOS, , WINDOWS[OS][version] (z. B. IOS15_1),[OS][version]_OR_GREATER (z. B. IOS15_1_OR_GREATER) |
Hinweis
- Versionslose Symbole werden unabhängig von der Version definiert, die Sie als Ziel verwenden.
- Versionsspezifische Symbole werden nur für die Version definiert, die Sie als Ziel verwenden.
- Die
<framework>_OR_GREATER-Symbole werden für die Zielversion und alle früheren Versionen definiert. Wenn Sie beispielsweise .NET Framework 2.0 als Ziel festgelegt haben, werden die folgenden Symbole definiert:NET20,NET20_OR_GREATER,NET11_OR_GREATERundNET10_OR_GREATER. - Die
NETSTANDARD<x>_<y>_OR_GREATER-Symbole werden nur für .NET Standard-Ziele definiert und nicht für Ziele, die .NET Standard implementieren, z. B. .NET Core und .NET Framework. - Diese unterscheiden sich von den Zielframeworkmonikern (TFMs), die von der
TargetFramework-Eigenschaft von MSBuild und NuGet verwendet werden.
Veraltete Zielframeworks
Die folgenden Zielframeworks sind veraltet. Pakete, die auf diese Zielframeworks ausgelegt sind, sollten in das jeweilige Nachfolgeframework migriert werden.
| Veralteter TFM | Ersetzung |
|---|---|
| aspnet50 aspnetcore50 dnxcore50 Dnx dnx45 dnx451 dnx452 |
netcoreapp |
| dotnet dotnet50 dotnet51 dotnet52 dotnet53 dotnet54 dotnet55 dotnet56 |
netstandard |
| netcore50 | uap10.0 |
| gewinnen | netcore45 |
| win8 | netcore45 |
| win81 | netcore451 |
| win10 | uap10.0 |
| winrt | netcore45 |
Weitere Informationen
Arbeiten Sie mit uns auf GitHub zusammen
Die Quelle für diesen Inhalt finden Sie auf GitHub, wo Sie auch Issues und Pull Requests erstellen und überprüfen können. Weitere Informationen finden Sie in unserem Leitfaden für Mitwirkende.
