Was ist der Unterschied zwischen den Projekttypen .NET Core und .NET Standard Class Library?

In Visual Studio können Sie mindestens drei verschiedene Arten von Klassenbibliotheken erstellen:

• Klassenbibliothek (.NET Framework)
• Klassenbibliothek (.NET Standard)
• Klassenbibliothek (.NET Core)

Während das erste das ist, was wir seit Jahren verwenden, ist ein Hauptverwirrungspunkt, den ich hatte, wann die Bibliothekstypen .NET Standard und .NET Core zu verwenden sind. Dies hat mich kürzlich gebissen, als ich versuchte, verschiedene Framework-Versionen auf mehrere Ziele auszurichten und ein Unit-Test-Projekt zu erstellen .

Was ist der Unterschied zwischen der Klassenbibliothek (.NET Standard) und der Klassenbibliothek (.NET Core) , warum gibt es beide und wann sollten wir sie übereinander verwenden?

Wann sollten wir eins über das andere verwenden?

Die Entscheidung ist ein Kompromiss zwischen Kompatibilität und API-Zugriff.

Verwenden Sie eine .NET-Standardbibliothek, wenn Sie die Anzahl der Apps erhöhen möchten, die mit Ihrer Bibliothek kompatibel sind, und wenn Sie die .NET-API-Oberfläche, auf die Ihre Bibliothek zugreifen kann, verringern können.

Verwenden Sie eine .NET Core-Bibliothek, wenn Sie die .NET API-Oberfläche vergrößern möchten, auf die Ihre Bibliothek zugreifen kann, und Sie können nur zulassen, dass nur .NET Core-Apps mit Ihrer Bibliothek kompatibel sind.

Eine Bibliothek, die auf .NET Standard 1.3 abzielt, ist beispielsweise mit Apps kompatibel , die auf .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0 und jede andere Plattform, die .NET Standard 1.3 unterstützt, abzielen. Die Bibliothek hat jedoch keinen Zugriff auf einige Teile der .NET-API. Das Microsoft.NETCore.CoreCLRPaket ist beispielsweise mit .NET Core kompatibel, jedoch nicht mit .NET Standard.

Was ist der Unterschied zwischen der Klassenbibliothek (.NET Standard) und der Klassenbibliothek (.NET Core)?

Der Abschnitt Paketbasierte Frameworks beschreibt den Unterschied.

Kompatibilität: Bibliotheken, die auf .NET Standard abzielen, können auf jeder .NET Standard-kompatiblen Laufzeit ausgeführt werden, z. B. .NET Core, .NET Framework, Mono / Xamarin. Bibliotheken, die auf .NET Core abzielen, können jedoch nur zur Laufzeit von .NET Core ausgeführt werden.

API-Oberfläche: .NET Standard-Bibliotheken enthalten alles, NETStandard.Librarywährend .NET Core-Bibliotheken alles enthalten Microsoft.NETCore.App. Letzteres enthält ungefähr 20 zusätzliche Bibliotheken, von denen einige manuell zu unserer .NET Standard-Bibliothek (z. B. System.Threading.Thread) hinzugefügt werden können und von denen einige nicht mit dem .NET Standard (z. B. Microsoft.NETCore.CoreCLR) kompatibel sind .

Außerdem geben .NET Core-Bibliotheken eine Laufzeit an und werden mit einem Anwendungsmodell geliefert. Dies ist beispielsweise wichtig, um Unit-Test-Klassenbibliotheken ausführbar zu machen.

Warum gibt es beides?

Wenn Sie Bibliotheken für einen Moment ignorieren, liegt der Grund für die Existenz von .NET Standard in der Portabilität. Es definiert eine Reihe von APIs, deren Implementierung .NET-Plattformen zustimmen. Jede Plattform, die einen .NET-Standard implementiert, ist mit Bibliotheken kompatibel, die auf diesen .NET-Standard abzielen. Eine dieser kompatiblen Plattformen ist .NET Core.

Zurück zu den Bibliotheken: Die .NET Standard-Bibliotheksvorlagen können auf mehreren Laufzeiten ausgeführt werden (auf Kosten der API-Oberfläche). Umgekehrt sind die .NET Core-Bibliotheksvorlagen vorhanden, um (auf Kosten der Kompatibilität) auf mehr API-Oberfläche zuzugreifen und eine Plattform anzugeben, auf der eine ausführbare Datei erstellt werden soll.

Hier ist eine interaktive Matrix , die zeigt, welcher .NET Standard welche .NET-Implementierung (en) unterstützt und wie viel API-Oberfläche verfügbar ist.

Eine .NET Core Class Library basiert auf dem .NET Standard . Wenn Sie eine Bibliothek implementieren möchten, die auf .NET Framework portierbar ist ,. Wählen Sie in .NET Core und Xamarin eine .NET-Standardbibliothek aus

.NET Core wird letztendlich .NET Standard 2 implementieren (ebenso wie Xamarin und .NET Framework ).

.NET Core , Xamarin und .NET Framework können daher als Varianten von .NET Standard identifiziert werden

Um Ihre Anwendungen für die gemeinsame Nutzung und Wiederverwendung von Code zukunftssicher zu machen, implementieren Sie lieber .NET Standard-Bibliotheken.

Microsoft empfiehlt außerdem, .NET Standard anstelle von Portable Class Libraries zu verwenden .

Zitieren MSDN als maßgebliche Quelle, .NET Standard - sollte seine One - Bibliothek knechten . Da Bilder mehr als tausend Worte sagen, wird Folgendes Folgendes deutlich machen:

1. Ihr aktuelles Anwendungsszenario (fragmentiert)

Wie die meisten von uns befinden Sie sich wahrscheinlich in der folgenden Situation: (.NET Framework-, Xamarin- und jetzt .NET Core-Anwendungen)

2. Was die .NET-Standardbibliothek für Sie ermöglicht (Cross-Framework-Kompatibilität)

Die Implementierung einer .NET-Standardbibliothek ermöglicht die gemeinsame Nutzung von Code in all diesen verschiedenen Varianten:

Für die Ungeduldigen:

1. .NET Standard löst das Problem der Codefreigabe für .NET-Entwickler auf allen Plattformen, indem alle APIs, die Sie erwarten und lieben, in den von Ihnen benötigten Umgebungen bereitgestellt werden: Desktopanwendungen, mobile Apps und Spiele sowie Cloud-Dienste:
2. .NET Standard ist eine Reihe von APIs , die alle .NET-Plattformen implementieren müssen . Dies vereinheitlicht die .NET-Plattformen und verhindert eine zukünftige Fragmentierung .
3. .NET Standard 2.0 wird von .NET Framework implementiert . NET Core und Xamarin . Für .NET Core werden dadurch viele der vorhandenen APIs hinzugefügt, die angefordert wurden.
4. .NET Standard 2.0 enthält einen Kompatibilitäts-Shim für .NET Framework- Binärdateien, wodurch die Anzahl der Bibliotheken, auf die Sie in Ihren .NET Standard-Bibliotheken verweisen können, erheblich erweitert wird.
5. .NET Standard wird Portable Class Libraries (PCLs) als Tooling Story für die Erstellung plattformübergreifender .NET-Bibliotheken ersetzen .

Eine Tabelle zum besseren Verständnis der höchsten Version von .NET Standard, auf die Sie abzielen können, basierend auf den .NET-Plattformen, auf denen Sie ausgeführt werden sollen, finden Sie hier .

Quellen: MSDN: Einführung in .NET Standard

Die kurze Antwort wäre also:

IAnimal == .NetStandard (General)
ICat == .NetCore (Less General)
IDog == .NetFramework (Specific / oldest and has the most features)

.NET und .NET Core sind zwei verschiedene Implementierungen der .NET-Laufzeit. Sowohl Core als auch Framework (insbesondere Framework) haben unterschiedliche Profile, die größere oder kleinere (oder einfach nur unterschiedliche) Auswahlen der vielen APIs und Assemblys enthalten, die Microsoft für .NET erstellt hat, je nachdem, wo sie installiert sind und in welchem ​​Profil.

Beispielsweise sind in Universal Windows-Apps einige andere APIs verfügbar als im "normalen" Windows-Profil. Selbst unter Windows haben Sie möglicherweise das Profil "Client" im Vergleich zum Profil "Voll". Darüber hinaus gibt es andere Implementierungen (wie Mono ), die über eigene Bibliotheksgruppen verfügen.

.NET Standard ist eine Spezifikation, für die Sätze von API-Bibliotheken und Assemblys verfügbar sein müssen. Eine für .NET Standard 1.0 geschriebene App sollte in der Lage sein, mit jeder Version von Framework, Core, Mono usw. zu kompilieren und auszuführen, die Unterstützung für die .NET Standard 1.0-Bibliothekssammlung ankündigt. Ähnliches gilt für .NET Standard 1.1, 1.5, 1.6, 2.0 usw. Solange die Laufzeit die von Ihrem Programm anvisierte Standardversion unterstützt, sollte Ihr Programm dort ausgeführt werden.

Ein Projekt, das auf eine Version von Standard abzielt, kann keine Funktionen verwenden, die in dieser Überarbeitung des Standards nicht enthalten sind. Dies bedeutet nicht, dass Sie keine Abhängigkeiten von anderen Assemblys oder APIs übernehmen können, die von anderen Anbietern veröffentlicht wurden (z. B. Elemente in NuGet). Dies bedeutet jedoch, dass alle Abhängigkeiten, die Sie annehmen, auch Unterstützung für Ihre Version von .NET Standard enthalten müssen. .NET Standard entwickelt sich schnell weiter, ist aber noch neu genug und kümmert sich genug um einige der kleineren Laufzeitprofile, sodass sich diese Einschränkung erstickend anfühlt. (Beachten Sie anderthalb Jahre später: Dies beginnt sich zu ändern, und die neuesten .NET Standard-Versionen sind viel schöner und umfassender.)

Auf der anderen Seite, eine App bei Standard gezielte sollte die Lage sein , in mehr Einsatzsituationen verwendet werden, da in der Theorie mit Core - Framework, Mono, etc. Für eine Klassenbibliothek Projekt sucht breite Verteilung ausführen kann, die ein attraktives Versprechen ist . Bei einem Klassenbibliotheksprojekt, das hauptsächlich für interne Zwecke verwendet wird, ist dies möglicherweise nicht so wichtig.

.NET Standard kann auch in Situationen nützlich sein, in denen das Systemadministratorteam aus philosophischen oder Kostengründen von ASP.NET unter Windows zu ASP.NET für .NET Core unter Linux wechseln möchte, das Entwicklungsteam jedoch weiterhin dagegen arbeiten möchte. NET Framework in Visual Studio unter Windows.

.NET Framework und .NET Core sind beide Frameworks.

.NET Standard ist ein Standard (mit anderen Worten eine Spezifikation).

Sie können ein ausführbares Projekt (wie eine Konsolenanwendung oder eine ASP.NET-Anwendung) mit .NET Framework und .NET Core erstellen, jedoch nicht mit .NET Standard.

Mit .NET Standard können Sie nur ein Klassenbibliotheksprojekt erstellen, das nicht eigenständig ausgeführt werden kann und auf das von einem anderen ausführbaren .NET Core- oder .NET Framework-Projekt verwiesen werden sollte.

Ich hoffe, dies hilft, die Beziehung zwischen der .NET Standard-API-Oberfläche und anderen .NET-Plattformen zu verstehen . Jede Schnittstelle repräsentiert ein Zielframework und Methoden repräsentieren Gruppen von APIs, die auf diesem Zielframework verfügbar sind.

namespace Analogy
{
  // .NET Standard

interface INetStandard10
{
    void Primitives();
    void Reflection();
    void Tasks();
    void Xml();
    void Collections();
    void Linq();
}

interface INetStandard11 : INetStandard10
{
    void ConcurrentCollections();
    void LinqParallel();
    void Compression();
    void HttpClient();
}

interface INetStandard12 : INetStandard11
{
    void ThreadingTimer();
}

interface INetStandard13 : INetStandard12
{
    //.NET Standard 1.3 specific APIs
}

// And so on ...


// .NET Framework 

interface INetFramework45 : INetStandard11
{
    void FileSystem();
    void Console();
    void ThreadPool();
    void Crypto();
    void WebSockets();
    void Process();
    void Drawing();
    void SystemWeb();
    void WPF();
    void WindowsForms();
    void WCF();
}

interface INetFramework451 : INetFramework45, INetStandard12
{
    // .NET Framework 4.5.1 specific APIs
}

interface INetFramework452 : INetFramework451, INetStandard12
{
    // .NET Framework 4.5.2 specific APIs
}

interface INetFramework46 : INetFramework452, INetStandard13
{
    // .NET Framework 4.6 specific APIs
}

interface INetFramework461 : INetFramework46, INetStandard14
{
    // .NET Framework 4.6.1 specific APIs
}

interface INetFramework462 : INetFramework461, INetStandard15
{
    // .NET Framework 4.6.2 specific APIs
}

// .NET Core
interface INetCoreApp10 : INetStandard15
{
    // TODO: .NET Core 1.0 specific APIs
}
// Windows Universal Platform
interface IWindowsUniversalPlatform : INetStandard13
{
    void GPS();
    void Xaml();
}

// Xamarin 
interface IXamarinIOS : INetStandard15
{
    void AppleAPIs();
}

interface IXamarinAndroid : INetStandard15
{
    void GoogleAPIs();
}    
// Future platform

interface ISomeFuturePlatform : INetStandard13
{
    // A future platform chooses to implement a specific .NET Standard version.
    // All libraries that target that version are instantly compatible with this new
    // platform
}
}

Quelle

Eine andere Möglichkeit, den Unterschied zu erklären, könnten Beispiele aus der Praxis sein, da die meisten von uns Sterblichen vorhandene Tools und Frameworks (Xamarin, Unity usw.) verwenden, um die Arbeit zu erledigen.

Mit .NET Framework können Sie also mit allen .NET-Tools arbeiten, aber Sie können nur auf Windows-Anwendungen (UWP, Winforms, ASP.NET usw.) abzielen. Da .NET Framework Closed Source ist, gibt es nicht viel zu tun.

Mit .NET Core haben Sie weniger Tools, können jedoch auf die wichtigsten Desktop-Plattformen (Windows, Linux, Mac) abzielen. Dies ist besonders nützlich in ASP.NET Core-Anwendungen, da Sie Asp.net jetzt unter Linux hosten können (günstigere Hosting-Preise). Da .NET Core Open Source war, ist es technisch möglich, Bibliotheken für andere Plattformen zu entwickeln. Aber da es keine Frameworks gibt, die dies unterstützen, halte ich das nicht für eine gute Idee.

Mit .NET Standard haben Sie noch weniger Tools, aber Sie können auf alle / die meisten Plattformen abzielen. Dank Xamarin können Sie auf Mobilgeräte und dank Mono / Unity sogar auf Spielekonsolen abzielen. Update: Es ist auch möglich, Web-Clients mit UNO-Plattform und Blazor anzusprechen (obwohl beide derzeit etwas experimentell sind).

In einer realen Anwendung müssen Sie möglicherweise alle verwenden. Zum Beispiel habe ich eine Point-of-Sale-Anwendung entwickelt, die die folgende Architektur hat:

Server und Client gemeinsam genutzt:

• Eine .NET Standard-Bibliothek, die die Modelle meiner Anwendung verarbeitet.
• Eine .NET Standard-Bibliothek, die die Validierung der von den Clients gesendeten Daten übernimmt.

Da es sich um eine .NET Standard-Bibliothek handelt, kann sie in jedem anderen Projekt (Client und Server) verwendet werden.

Auch ein schöner Vorteil der Validierung in einer .NET-Standardbibliothek, da ich sicher sein kann, dass dieselbe Validierung auf dem Server und dem Client angewendet wird. Der Server ist obligatorisch, während der Client optional und nützlich ist, um den Datenverkehr zu reduzieren.

Serverseitig (Web-API):

• Eine .NET Standard-Bibliothek (könnte auch Core sein), die alle Datenbankverbindungen verarbeitet.

• Ein .NET Core-Projekt, das die Rest-API verwaltet und die Datenbankbibliothek verwendet.

Da dies in .NET Core entwickelt wurde, kann ich die Anwendung auf einem Linux-Server hosten.

Client-Seite (MVVM mit WPF + Xamarin.Forms Android / IOS):

• Eine .NET Standard-Bibliothek, die die Client-API-Verbindung verwaltet.

• Eine .NET Standard-Bibliothek, die die ViewModels-Logik verarbeitet. Wird in allen Ansichten verwendet.

• Eine .NET Framework-WPF-Anwendung, die die WPF-Ansichten für eine Windows-Anwendung verarbeitet. Update: WPF-Anwendungen können jetzt .NET-Kern sein, obwohl sie derzeit nur unter Windows funktionieren. AvaloniaUI ist eine gute Alternative zum Erstellen von Desktop-GUI-Anwendungen für andere Desktop-Plattformen.

• Eine .NET Standard-Bibliothek, die Xamarin Forms-Ansichten verarbeitet.

• Ein Xamarin Android- und Xamarin IOS-Projekt.

Sie sehen also, dass es hier auf der Clientseite der Anwendung einen großen Vorteil gibt, da ich beide .NET Standard-Bibliotheken (Client-API und ViewModels) wiederverwenden und nur Ansichten ohne Logik für die WPF-, Xamarin- und IOS-Anwendungen erstellen kann.

.NET Standard: Stellen Sie sich das als große Standardbibliothek vor. Wenn Sie dies als Abhängigkeit verwenden, können Sie nur Bibliotheken (.DLLs) erstellen, keine ausführbaren Dateien. Eine Bibliothek, die mit dem .NET-Standard als Abhängigkeit erstellt wurde, kann einem Xamarin.Android-, einem Xamarin.iOS- und einem .NET Core-Windows / OS X / Linux-Projekt hinzugefügt werden.

.NET Core: Stellen Sie sich das als Fortsetzung des alten .NET Frameworks vor, es ist nur Open Source und einige Dinge sind noch nicht implementiert und andere sind veraltet. Es erweitert den .NET-Standard um zusätzliche Funktionen, läuft jedoch nur weiter Desktops . Wenn Sie dies als Abhängigkeit hinzufügen, können Sie ausführbare Anwendungen unter Windows, Linux und OS X erstellen. (Obwohl Konsole nur für den Moment, keine GUIs). Also .NET Core = .NET Standard + Desktop-spezifisches Zeug.

Auch UWP verwendet es und der neue ASP.NET Core verwendet es auch als Abhängigkeit.

.NET Standard dient hauptsächlich dazu, die Codefreigabe zu verbessern und die APIs in jeder .NET-Implementierung konsistenter zu machen.

Beim Erstellen von Bibliotheken können wir das Ziel als .NET Standard 2.0 festlegen, damit die erstellte Bibliothek mit verschiedenen Versionen von .NET Framework kompatibel ist, einschließlich .NET Core, Mono usw.

Die obigen Antworten beschreiben möglicherweise das beste Verständnis für den Unterschied zwischen Netzkern, Netzstandard und Netzrahmen. Ich möchte daher nur meine Erfahrungen teilen, wenn ich dies über das wähle.

In dem Projekt, das Sie zwischen .NET Framework, .NET Core und .NET Standard mischen müssen. Zum Zeitpunkt der Erstellung des Systems mit .NET Core 1.0 wird beispielsweise das Hosting von Windows Services mit .net Core nicht unterstützt.

Der nächste Grund ist, dass wir Active Report verwendet haben, das .NET Core nicht unterstützt. Daher möchten wir eine Infrastrukturbibliothek erstellen, die sowohl für .NET Core (asp.net core) als auch für Windows Service and Reporting (.NET Framework) verwendet werden kann. - Aus diesem Grund haben wir .NET Standard für diese Art von Bibliothek ausgewählt. Wenn Sie sich für den .NET-Standard entscheiden, müssen Sie sorgfältig prüfen, ob jede Klasse in der Bibliothek einfach und übergreifend .NET (Kern, Framework, Standard) sein sollte.

Fazit:

• .NET Standard für die Infrastrukturbibliothek und gemeinsam genutzt. Auf diese Bibliothek kann von .NET Framework und .NET Core verwiesen werden.
• .NET Framework für nicht unterstützte Technologien wie Active Report, Window Services (jetzt mit .NET 3.0 unterstützt).
• .NET Core für ASP.NET Core natürlich.

Microsoft hat gerade .NET 5 angekündigt: https://devblogs.microsoft.com/dotnet/introducing-net-5/

.NET Framework Windows Form-, ASP.NET- und WPF-Anwendungen müssen mithilfe der .NET Framework-Bibliothek entwickelt werden

.NET Standard Xamarin-, IOs- und MAC OSx-Anwendungen müssen mithilfe der .NET Standard-Bibliothek entwickelt werden

Die .NET Core
Universal Windows Platform (UWP) - und Linux-Anwendung muss mithilfe der .NET Core-Bibliothek entwickelt werden. Die API ist in C ++ implementiert und Sie können C ++, VB.NET, C #, F # und Javascript verwenden

Eine .Net Core Class Library basiert auf dem .Net Standard. Wenn Sie eine Bibliothek implementieren möchten, die auf das .Net Framework, .Net Core und Xamarin portierbar ist, wählen Sie eine .Net-Standardbibliothek