.NET Standard

.NET Standard ist eine formale Spezifikation .NET APIs, die für mehrere .NET Implementierungen verfügbar sind. Die Motivation hinter .NET Standard bestand darin, im .NET Ökosystem eine größere Einheitlichkeit zu schaffen. .NET 5 und neueren Versionen haben einen anderen Ansatz zur Festlegung der Einheitlichkeit, die in den meisten Szenarien die Notwendigkeit von .NET Standard beseitigt. Wenn Sie jedoch Code zwischen .NET Framework und einer anderen .NET Implementierung freigeben möchten, z. B. .NET Core, sollte Ihre Bibliothek auf .NET Standard 2.0 abzielen. Keine neuen Versionen von .NET Standard werden veröffentlicht, aber .NET 5 und alle späteren Versionen unterstützen weiterhin .NET Standard 2.1 und früher.

Informationen zum Auswählen zwischen .NET 5+ und .NET Standard finden Sie unter .NET 5+ und .NET Standard weiter unten in diesem Artikel.

.NET Standardversionen

.NET Standard ist versioniert. Jede neue Version fügt weitere APIs hinzu. Wenn eine Bibliothek mit einer bestimmten Version von .NET Standard erstellt wird, kann sie auf jeder .NET Implementierung ausgeführt werden, die diese Version von .NET Standard (oder höher) implementiert.

Eine höhere Version des .NET Standard ermöglicht einer Bibliothek, mehr APIs zu verwenden, hat jedoch zur Folge, dass sie nur auf neueren Versionen von .NET genutzt werden kann. Die Ausrichtung auf eine niedrigere Version reduziert die verfügbaren APIs, bedeutet jedoch, dass die Bibliothek an mehr Stellen ausgeführt werden kann.

Wählen Sie .NET Standardversion aus.

Welche .NET Standardversion als Ziel verwendet werden soll

Wenn Sie auf .NET Standard abzielen, empfehlen wir, .NET Standard 2.0 als Ziel zu verwenden, es sei denn, Sie müssen eine frühere Version unterstützen. Die meisten allgemeinen Bibliotheken sollten keine APIs außerhalb von .NET Standard 2.0 benötigen, und .NET Framework unterstützt nicht .NET Standard 2.1. .NET Standard 2.0 wird von allen modernen Plattformen unterstützt und ist die empfohlene Möglichkeit, mehrere Plattformen mit einem Ziel zu unterstützen.

Wenn Sie .NET Standard 1.x unterstützen müssen, empfehlen wir, auch auf .NET Standard 2.0 abzuzielen. .NET Standard 1.x wird als granularer Satz von NuGet-Paketen verteilt, wodurch ein großes Paketabhängigkeitsdiagramm erstellt wird und viele Pakete heruntergeladen werden, wenn das Projekt erstellt wird. Weitere Informationen finden Sie unter Cross-platform targeting und .NET 5+ und .NET Standard weiter unten in diesem Artikel.

.NET Standardversionsverwaltungsregeln

Es gibt zwei primäre Versionskontrollregeln:

• Additive: .NET Standardversionen sind logisch konzentrische Kreise: Höhere Versionen enthalten alle APIs aus früheren Versionen. Zwischen den Versionen gibt es keine kompatibilitätsbrechenden Änderungen.
• Unveränderlich: Nach der Bereitstellung werden .NET Standardversionen eingefroren.

Nach 2.1 gibt es keine neuen .NET Standardversionen. Weitere Informationen finden Sie unter .NET 5+ und .NET Standard weiter unten in diesem Artikel.

Spezifikation

Die .NET Standardspezifikation ist ein standardisierter Satz von APIs. Die Spezifikation wird von .NET Implementierern verwaltet, insbesondere von Microsoft (einschließlich .NET Framework, .NET Core und Mono) und Unity.

Offizielle Artefakte

Die offizielle Spezifikation ist eine Reihe von CS-Dateien zur Definition der APIs, die Bestandteile des Standards sind. Das verzeichnis ref im (jetzt archivierten) dotnet/standard repository definiert die .NET Standard-APIs.

Die NETStandard.Library metapackage (source) beschreibt den Satz von Bibliotheken, die (teilweise) eine oder mehrere .NET Standardversionen definieren.

Eine bestimmte Komponente wie System.Runtime beschreibt Folgendes:

• Teil des .NET Standards (nur dessen Umfang).
• Mehrere Versionen von .NET Standard für diesen Bereich.

Abgeleitete Elemente werden bereitgestellt, um ein einfacheres Lesen und bestimmte Entwicklungsszenarios (z.B. die Verwendung eines Compilers) zu ermöglichen.

• API-Liste in Markdown.
• Referenzassemblys, die als NuGet-Pakete verteilt und vom Metapaket NETStandard.Library referenziert werden.

Paketdarstellung

Das primäre Distributionsmittel für die .NET Standard-Verweisassemblys ist das NuGet-Paket. Implementierungen werden auf unterschiedliche Weise bereitgestellt, die für jede .NET Implementierung geeignet sind.

NuGet-Pakete sind auf mindestens ein Framework ausgerichtet. .NET Standardpakete zielen auf das Framework ".NET Standard" ab. Sie können das .NET Standardframework mit dem netstandardcompact Target Framework moniker (TFM) z. B. netstandard1.4 ausrichten. Bibliotheken, die für mehrere Implementierungen von .NET ausgeführt werden sollen, sollten auf das .NET Standardframework abzielen. Um die größte Anzahl an APIs zu nutzen, richten Sie sich auf netstandard2.0 aus, da sich die Anzahl der verfügbaren APIs zwischen .NET Standard 1.6 und 2.0 mehr als verdoppelt hat.

Die NETStandard.Library metapackage verweist auf den vollständigen Satz von NuGet-Paketen, die .NET Standard definieren. Die gängigste Methode, netstandard als Ziel auszuwählen, ist das Verweisen auf dieses Metapaket. Es beschreibt und bietet Zugriff auf die ~40 .NET-Bibliotheken und zugeordneten APIs, die .NET Standard definieren. Sie können auf zusätzliche Pakete verweisen, die netstandard als Ziel verwenden, um Zugriff auf weitere APIs zu erhalten.

Versionskontrolle

Die Spezifikation ist nicht singulär, sondern eine Reihe linear versionierter APIs. In der ersten Version des Standards wird ein Basissatz von APIs eingerichtet. Nachfolgende Versionen fügen APIs hinzu und erben APIs, die in früheren Versionen definiert wurden. Es gibt keine festgelegte Möglichkeit zum Entfernen von APIs aus dem Standard.

.NET Standard ist weder für eine .NET Implementierung spezifisch, noch stimmt sie mit dem Versionsverwaltungsschema einer dieser Implementierungen überein.

Wie bereits erwähnt, gibt es nach 2.1 keine neuen .NET Standardversionen.

Target .NET Standard

Sie können .NET Standardbibliotheken erstellen, indem Sie eine Kombination aus dem netstandard Framework und dem NETStandard.Library Metapaket verwenden.

.NET Framework-Kompatibilitätsmodus

Ab .NET Standard 2.0 wurde der .NET Framework-Kompatibilitätsmodus eingeführt. Mit diesem Kompatibilitätsmodus können .NET Standardprojekte auf .NET Framework-Bibliotheken verweisen, als ob sie für .NET Standard kompiliert wurden. Das Verweisen auf .NET Framework-Bibliotheken funktioniert nicht für alle Projekte, z. B. Bibliotheken, die Windows Presentation Foundation -APIs (WPF) verwenden.

Weitere Informationen finden Sie unter .NET Framework-Kompatibilitätsmodus.

.NET Standardbibliotheken und Visual Studio

Um .NET Standardbibliotheken in Visual Studio zu erstellen, stellen Sie sicher, dass sie Visual Studio 2019 oder höher oder Visual Studio 2017, Version 15.3 oder höher, auf Windows installiert haben.

Wenn Sie nur .NET Standard 2.0-Bibliotheken in Ihren Projekten verwenden müssen, können Sie dies auch in Visual Studio 2015 tun. Allerdings muss dabei der NuGet-Client 3.6 oder höher installiert sein. Sie können den NuGet-Client für Visual Studio 2015 von der NuGet-Downloadseite herunterladen.

.NET 5+ und .NET Standard

.NET 5, .NET 6, .NET 7, .NET 8, .NET 9 und .NET 10 sind einzelne Produkte mit einem einheitlichen Satz von Funktionen und APIs, die für Windows Desktop-Apps und plattformübergreifende Konsolen-Apps, Clouddienste und Websites verwendet werden können. Die .NET 10 TFMs spiegeln beispielsweise diese breite Palette von Szenarien wider:

• net10.0

  Dieser TFM ist für Code bestimmt, der überall ausgeführt werden kann. Mit wenigen Ausnahmen sind nur Technologien enthalten, die plattformübergreifend funktionieren.

• net10.0-windows

  Dies ist ein Beispiel für ein betriebssystemspezifisches TFM , das betriebssystemspezifische Funktionen zu allem hinzufügt, auf das net10.0 verwiesen wird.

Wann sollte netx.0 und wann netstandard als Ziel verwendet werden?

Für vorhandenen Code, der auf .NET Standard 2.0 oder höher ausgerichtet ist, muss der TFM nicht in net8.0 oder höher geändert werden. .NET 8, .NET 9 und .NET 10 implementieren .NET Standard 2.1 und früher. Der einzige Grund, um von .NET Standard auf .NET 8+ umzusteigen, wäre der Zugriff auf weitere Laufzeitfeatures, Sprachfeatures oder APIs. Um z. B. C# 9 zu verwenden, müssen Sie .NET 5 oder eine höhere Version als Ziel festlegen. Sie können .NET und .NET Standard multitargetieren, um Zugriff auf neuere Features zu erhalten und ihre Bibliothek weiterhin für andere .NET Implementierungen verfügbar zu haben.

Hier sind einige Richtlinien für neuen Code für .NET 5+:

• App-Komponenten

  Wenn Sie Bibliotheken verwenden, um eine Anwendung in mehrere Komponenten zu unterteilen, wird empfohlen, net10.0 als Ziel zu verwenden. Der Einfachheit halber empfiehlt es sich, alle Projekte beizubehalten, aus denen Ihre Anwendung in derselben Version von .NET besteht. Dann können Sie dieselben BCL-Features überall verwenden.

• Wiederverwendbare Bibliotheken

  Wenn Sie wiederverwendbare Bibliotheken erstellen, die NuGet enthalten soll, sollten Sie den Kompromiss zwischen Reichweite und verfügbaren Features berücksichtigen. .NET Standard 2.0 ist die neueste Version, die von .NET Framework unterstützt wird, sodass es eine gute Reichweite mit einem ziemlich großen Featuresatz bietet. Es wird nicht empfohlen, .NET Standard 1.x zu verwenden, da Sie den verfügbaren Featuresatz auf eine minimale Erhöhung der Reichweite beschränken.

  Wenn Sie .NET Framework nicht unterstützen müssen, können Sie auf .NET Standard 2.1 oder .NET 10 abzielen. Es wird empfohlen, .NET Standard 2.1 zu überspringen und direkt zu .NET 10 zu wechseln. Die am häufigsten verwendeten Bibliotheken unterstützen sowohl .NET Standard 2.0 als auch .NET 5+ durch Multi-Targeting. Wenn Sie .NET Standard 2.0 unterstützen, erhalten Sie die größtmögliche Reichweite, während sie .NET 5+ unterstützt, um sicherzustellen, dass Sie die neuesten Plattformfeatures für Kunden nutzen können, die bereits auf .NET 5+ installiert sind.

.NET Standardprobleme

Hier sind einige Probleme mit .NET Standard, die erläutern, warum .NET 5 und höhere Versionen die bessere Möglichkeit sind, Code über Plattformen und Workloads hinweg zu teilen:

• Langsames Hinzufügen neuer APIs

  .NET Standard wurde als API-Satz erstellt, den alle .NET Implementierungen unterstützen müssen. Daher gab es einen Überprüfungsprozess für Vorschläge zum Hinzufügen neuer APIs. Ziel war es, nur APIs zu standardisieren, die in allen aktuellen und zukünftigen .NET Plattformen implementiert werden konnten. Dies hatte zur Folge, dass Sie möglicherweise einige Jahre warten mussten, bis ein Feature, das zuvor nicht in einem Release verfügbar war, zu einer Version des Standards hinzugefügt wurde. Dann warten Sie noch länger, bis die neue Version von .NET Standard weit unterstützt wird.

  Solution in .NET 5+: Wenn ein Feature implementiert wird, ist es bereits für jede .NET 5+-App und -Bibliothek verfügbar, da die Codebasis freigegeben ist. Und da es keinen Unterschied zwischen der API-Spezifikation und deren Implementierung gibt, können Sie neue Features viel schneller nutzen als mit .NET Standard.

• Komplexe Versionsverwaltung

  Die Trennung der API-Spezifikation von ihren Implementierungen führt zu einer komplexen Zuordnung zwischen API-Spezifikationsversionen und Implementierungsversionen. Diese Komplexität wird in der zuvor in diesem Artikel gezeigten Tabelle und in den Anweisungen zur Interpretation erläutert.

  Solution in .NET 5+: Es gibt keine Trennung zwischen einer .NET 5+-API-Spezifikation und deren Implementierung. Das Ergebnis ist ein vereinfachtes TFM-Schema. Es gibt ein TFM-Präfix für alle Workloads: net10.0 wird für Bibliotheken, Konsolen-Apps und Web-Apps verwendet. Die einzige Variation ist ein Suffix, das plattformspezifische APIs für eine bestimmte Plattform angibt (z. B. net10.0-windows). Dank dieser TFM-Namenskonvention können Sie leicht erkennen, ob eine bestimmte App eine bestimmte Bibliothek verwenden kann. Es ist keine Versionsnummernentsprechungstabelle erforderlich, z. B. die für .NET Standard.

• Nicht unterstützte Plattform-Laufzeitausnahmen

  .NET Standard macht plattformspezifische APIs verfügbar. Der Code wird möglicherweise fehlerfrei kompiliert und scheint auf jede beliebige Plattform portierbar zu sein, auch wenn er nicht portierbar ist. Wenn sie auf einer Plattform ausgeführt wird, die keine Implementierung für eine bestimmte API hat, erhalten Sie Laufzeitfehler.

  Solution in .NET 5+: Die .NET 5+ SDKs enthalten Standardmäßig aktivierte Codeanalysatoren. Das Analysetool für die Plattformkompatibilität erkennt die unbeabsichtigte Verwendung von APIs, die auf den Plattformen, auf denen Sie sie ausführen möchten, nicht unterstützt werden. Weitere Informationen finden Sie unter Plattformkompatibilitätsanalyse.

.NET Standard nicht veraltet

.NET Standard ist weiterhin für Bibliotheken erforderlich, die von mehreren .NET Implementierungen verwendet werden können. Es wird empfohlen, .NET Standard in den folgenden Szenarien als Ziel zu verwenden:

• Verwenden Sie netstandard2.0, um Code zwischen .NET Framework und allen anderen Implementierungen von .NET zu teilen.
• Verwenden Sie netstandard2.1, um Code zwischen Mono und .NET Core 3.x zu teilen.

Siehe auch

• .NET Standardversionen (Source)
• .NET Standardversionen (interaktive Ui)
• Build a .NET Standard library
• Plattformübergreifendes Targeting