Plattformübergreifende Ziele

Modernes .NET unterstützt mehrere Betriebssysteme und Geräte. Es ist wichtig, dass .NET-Open-Source-Bibliotheken so viele Entwickler wie möglich unterstützen, unabhängig davon, ob sie eine in Azure gehostete ASP.NET-Website oder ein .NET-Spiel in Unity erstellen.

Beim Auswählen von Zielframeworks für Ihre Bibliothek ist es wichtig, zwischen zwei verschiedenen Zielen zu unterscheiden:

• Moderne APIs und Muster: Ihre Bibliothek lehnt sich an die Vorteile der neuesten Versionen der .NET-Plattform. Sie verwenden moderne Sprachmuster und unterstützen erweiterte Bereitstellungsmodelle wie native Ahead-of-Time-Kompilierung auf der CoreCLR.
• Breite Zielbestimmung: Ihre Bibliothek unterstützt eine breite Palette von .NET-Implementierungen und -Versionen, um die Kompatibilität in verschiedenen Benutzerszenarien zu maximieren.

Diese Ziele erfordern nicht immer denselben Ansatz. Wenn Ihre Zielanwendungen alle moderne .NET verwenden, können Ihre Bibliotheken auf die gleichen modernen .NET-Versionen abzielen, ohne ältere Frameworks verwenden zu müssen.

.NET- und .NET Standard-Ziele

.NET- und .NET-Standard-Ziele bieten die beste Möglichkeit, einer .NET-Bibliothek plattformübergreifende Unterstützung hinzuzufügen.

• .NET-Versionen 5 bis 10 sind Implementierungen von .NET. Jede Version ist dabei ein einzelnes Produkt mit einheitlichen Funktionen und APIs, die für Windows-Desktop-Apps und plattformübergreifende Konsolen-Apps, Clouddienste und Websites verwendet werden können.
• .NET Standard ist eine Spezifikation von .NET-APIs, die für alle .NET-Implementierungen verfügbar sind. Wenn Sie Software für .NET Standard entwickeln, können Sie Bibliotheken erstellen, die nur APIs aus einer bestimmten Version von .NET Standard verwenden. Dies bedeutet, dass die Bibliotheken von allen Plattformen verwendet werden können, die diese Version von .NET Standard implementieren.

Einen Vergleich zwischen .NET und .NET Standard finden Sie unter .NET 5 und .NET Standard.

Wenn Ihr Projekt auf .NET oder .NET Standard ausgerichtet ist und erfolgreich kompiliert wird, garantiert es nicht, dass die Bibliothek auf allen Plattformen erfolgreich ausgeführt wird:

• Bei plattformspezifischen APIs tritt auf anderen Plattformen ein Fehler auf. Beispielsweise wird Microsoft.Win32.Registry unter Windows erfolgreich ausgeführt, gibt jedoch unter anderen Betriebssystemen PlatformNotSupportedException aus.
• APIs können sich unterschiedlich verhalten. Beispielsweise haben Reflektions-APIs unterschiedliche Leistungsmerkmale, wenn eine Anwendung eine Ahead-of-time-Kompilierung auf iOS oder UWP verwendet.

Tipp

Das .NET-Team stellt ein Analysetool für die Plattformkompatibilität an, mit dem Sie mögliche Probleme erkennen können.

✔️ Beginnen Sie damit, ein net8.0-Target oder später für neue Bibliotheken einzuschließen.

Für neue Bibliotheken bietet die Ausrichtung auf moderne .NET (z. B. .NET 8 oder höher) Zugriff auf die neuesten APIs und Leistungsverbesserungen und ermöglicht Features wie AOT und Kürzen. Moderne .NET-Versionen sind plattformübergreifend und bieten hervorragende Kompatibilität in Windows, Linux und macOS.

✔️ ERWÄGEN Sie das Einschließen eines netstandard2.0 Ziels, wenn Sie eine umfassende Kompatibilität oder .NET Framework-Unterstützung benötigen.

.NET Standard 2.0 wird von .NET Framework 4.6.1+ und allen modernen .NET-Implementierungen unterstützt. Schließen Sie dieses Ziel ein, wenn Sie .NET Framework-Anwendungen unterstützen müssen oder wenn Sie Bibliotheken für maximale Kompatibilität in verschiedenen .NET-Ökosystemen erstellen.

❌ Vermeiden Sie es, ein netstandard1.x-Ziel einzuschließen.

.NET Standard 1.x wird als ein granularer Satz von NuGet-Paketen verteilt, der ein großes Abhängigkeitsdiagramm erstellt und dazu führt, dass Entwickler beim Erstellen viele Pakete herunterladen. Moderne .NET-Implementierungen unterstützen .NET Standard 2.0. Sie sollten.NET Standard 1.x nur dann als Ziel verwenden, wenn Sie speziell auf eine ältere Plattform abzielen müssen.

✔️ Schließen Sie ein netstandard2.0-Ziel ein, wenn Sie ein netstandard1.x-Ziel benötigen.

Alle Plattformen, die .NET Standard 2.0 unterstützen, verwenden das netstandard2.0-Ziel und profitieren von einem kleineren Paketdiagramm, während ältere Plattformen noch funktionieren und auf die Verwendung des netstandard1.x-Ziels zurückgreifen.

❌ Fügen Sie kein .NET Standard-Ziel ein, wenn die Bibliothek auf einem plattformspezifischen App-Modell basiert.

Beispielsweise hängt eine Bibliothek eines UWP-Steuerelemente-Toolkit von einem Appmodell ab, das nur in UWP verfügbar ist. App-Modellspezifische APIs sind in .NET Standard nicht verfügbar.

❌ NICHT für netstandard2.0 veröffentlichen, wenn Ihr Projekt oder Ihre Abhängigkeiten mehrere Ziele verfolgen.

netstandard2.0 ist keine Runtime, und Projekte mit mehreren Zielen stellen eine Laufzeit-Framework-spezifische Bibliothek zur Verfügung, die benötigt wird, wenn sie auf anderen Frameworks ausgeführt werden.

Festlegung von Zielversionen

Manchmal müssen über Ihre Bibliotheken auf Framework-spezifische APIs zugreifen. Der beste Weg, Framework-spezifische APIs aufzurufen, ist die Verwendung der Festlegung von Zielversionen, die Ihr Projekt für viele .NET-Zielframeworks statt nur für eine erstellt.

Um Ihre Kunden davor zu schützen, Bibliotheken für einzelne Frameworks erstellen zu müssen, sollten Sie eine .NET Standard-Ausgabe sowie eine oder mehrere Framework-spezifische Ausgaben anstreben. Bei der Festlegung von Zielversionen werden alle Assemblys in einem einzigen NuGet-Paket verpackt. Die Benutzer können dann auf das gleiche Paket zurückgreifen, und NuGet wählt die passende Implementierung aus. Ihre .NET Standard-Bibliothek dient als Fallbackbibliothek, die überall verwendet wird, mit Ausnahme der Fälle, in denen Ihr NuGet-Paket eine Framework-spezifische Implementierung bietet. Die Festlegung von Zielversionen ermöglicht es Ihnen, die bedingte Kompilierung in Ihrem Code zu verwenden und Framework-spezifische APIs aufzurufen.

✔️ Erwägen Sie das Targeting von .NET-Implementierungen zusätzlich zu .NET Standard.

Das Targeting von .NET-Implementierungen ermöglichen es Ihnen, plattformspezifische APIs aufzurufen, die sich außerhalb von .NET-Standard befinden.

Dabei muss weiterhin der Support für .NET Standard gewährleistet sein. Lösen Sie sich stattdessen von der Implementierung und bieten Sie Funktions-APIs. Auf diese Weise kann Ihre Bibliothek überall verwendet werden und unterstützt die Aktivierung von Funktionen zur Laufzeit.

public static class GpsLocation
{
    // This project uses multi-targeting to expose device-specific APIs to .NET Standard.
    public static async Task<(double latitude, double longitude)> GetCoordinatesAsync()
    {
#if NET462
        return CallDotNetFrameworkApi();
#elif WINDOWS_UWP
        return CallUwpApi();
#else
        throw new PlatformNotSupportedException();
#endif
    }

    // Allows callers to check without having to catch PlatformNotSupportedException
    // or replicating the OS check.
    public static bool IsSupported
    {
        get
        {
#if NET462 || WINDOWS_UWP
            return true;
#else
            return false;
#endif
        }
    }
}

✔️ ERWÄGEN Sie die Festlegung von mehreren Zielversionen, auch wenn der Quellcode für alle Ziele identisch ist, wenn ihr Projekt Bibliotheks- oder Paketabhängigkeiten aufweist.

Die abhängigen (direkten oder nachgeschalteten) Pakete Ihres Projekts können möglicherweise dieselben Code-APIs verwenden, während sie in verschiedenen Versionen der abhängigen Assembly pro Zielframework umschlossen sind. Durch das Hinzufügen bestimmter Ziele wird sichergestellt, dass Ihre Consumer ihre Assemblybindungsumleitungen nicht hinzufügen oder aktualisieren müssen.

❌ VERMEIDEN Sie das Festlegen von mehreren Zielversionen sowie das Verwenden von .NET Standard als Ziel, wenn Ihr Quellcode für alle Ziele identisch ist und Ihr Projekt keine Bibliotheks- oder Paketabhängigkeiten aufweist.

Die .NET Standard-Assembly wird von NuGet automatisch verwendet. Das Targeting einzelner .NET-Implementierungen erhöht die *.nupkg-Größe, ohne dass sich daraus Vorteil ergeben.

✔️ ERWÄGEN SIE, ein Ziel für net462 hinzuzufügen, wenn Sie auch netstandard2.0 anvisieren.

Bei der Verwendung von .NET Standard 2.0 aus .NET Framework gibt es einige Probleme, die in .NET Framework 4.7.2 behoben wurden. Sie können das Erlebnis für Entwickler, die noch mit .NET Framework 4.6.2 bis 4.7.1 arbeiten, verbessern, indem Sie ihnen eine Binärdatei anbieten, die für .NET Framework 4.6.2 erstellt wurde.

✔️ DO Verteilen Sie Ihre Bibliothek mithilfe eines NuGet-Pakets.

NuGet wählt das beste Ziel für den Entwickler aus und schützt ihn davor, die passende Implementierung auswählen zu müssen.

✔️ Verwenden Sie bei der Festlegung von Zielversionen die TargetFrameworks-Eigenschaft der Projektdatei.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <!-- This project will output net8.0 and netstandard2.0 assemblies -->
    <TargetFrameworks>net8.0;netstandard2.0</TargetFrameworks>
  </PropertyGroup>
</Project>

❌ VERMEIDEN Sie das Ändern des Assemblynamens oder die Verwendung unterschiedlicher Assemblynamen für jede TFM, die Ihre Bibliothek kompiliert. Aufgrund von Abhängigkeiten zwischen Bibliotheken kann die Multiadressierung mit unterschiedlichen Assemblynamen pro TFM Paketverbraucher unterbrechen. Eine Assembly sollte für alle TFMs denselben Namen haben.

Ältere Ziele

.NET unterstützt die Festlegung von Zielversionen des .NET Framework, die seit langem nicht mehr unterstützt werden, sowie Plattformen, die nur noch selten verwendet werden. Es ist zwar sinnvoll, Ihre Bibliothek mit so vielen Zielen wie möglich arbeiten zu lassen, aber die Notwendigkeit, fehlende APIs zu umgehen, kann zu einem erheblichen Aufwand führen. Wir glauben, dass bestimmte Frameworks angesichts ihrer Reichweite und Grenzen nicht mehr als Ziel genutzt werden sollten.

❌ Schließen Sie keine portable Klassenbibliothek (PCL) als Ziel ein. Beispiel: portable-net45+win8+wpa81+wp8.

.NET Standard ist die moderne Möglichkeit, um plattformübergreifende .NET-Bibliotheken zu unterstützen und ist der Ersatz für PCLs.

❌ Schließen Sie keine Ziele für .NET-Plattformen ein, die nicht mehr unterstützt werden. Platzhalter in einer derartigen Schreibweise sind z.B. SL4 und WP.

ZurückWeiter