it-swarm.com.de

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

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 es ein wichtiger Punkt der Verwirrung, wann ich die Klassenbibliothekstypen .NET Standard und .NET Core verwende. Das hat mich kürzlich gebissen, als ich versuchte, verschiedene Framework-Versionen mit mehreren Zielen und ein Unit-Test-Projekt zu erstellen .

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

678
Gigi

Wann sollten wir eins übereinander 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 Sie mit einer Verringerung der .NET-API-Oberfläche einverstanden sind, auf die Ihre Bibliothek zugreifen kann.

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 in Ordnung sind, zuzulassen, dass nur .NET Core-Apps mit Ihrer Bibliothek kompatibel sind.

Beispiel: Eine Bibliothek, die auf .NET Standard 1.3 abzielt ist kompatibel mit Apps, die auf .NET Framework 4.6, .NET Core 1.0, die universelle Windows-Plattform 10.0 und jede andere Plattform abzielen, die .NET Standard 1.3 unterstützt . Die Bibliothek hat jedoch keinen Zugriff auf einige Teile der .NET-API. Beispielsweise ist das Paket Microsoft.NETCore.CoreCLR mit .NET Core kompatibel, jedoch nicht mit .NET Standard.

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

Der Abschnitt Package-based Frameworks beschreibt den Unterschied.

Kompatibilität: Bibliotheken, die auf .NET Standard abzielen, können auf jeder mit .NET Standard kompatiblen Laufzeit ausgeführt werden, z. B. .NET Core, .NET Framework, Mono/Xamarin. Auf der anderen Seite können Bibliotheken, die auf .NET Core abzielen, nur auf der .NET Core-Laufzeit ausgeführt werden.

API-Oberfläche: .NET Standard-Bibliotheken enthalten alles in _NETStandard.Library_, wohingegen .NET Core-Bibliotheken alles in _Microsoft.NETCore.App_ enthalten sind. Letzteres umfasst ungefähr 20 zusätzliche Bibliotheken, von denen einige manuell zu unserer .NET-Standardbibliothek hinzugefügt werden können (z. B. _System.Threading.Thread_) und von denen einige nicht mit dem .NET-Standard kompatibel sind (z. B. _Microsoft.NETCore.CoreCLR_ ).

.NET Core-Bibliotheken geben außerdem eine Laufzeit an und enthalten ein Anwendungsmodell. Dies ist zum Beispiel wichtig, um Unit-Test-Klassenbibliotheken lauffähig zu machen.

Warum gibt es beides?

Wenn Sie Bibliotheken für einen Moment ignorieren, besteht der Grund dafür, dass .NET Standard vorhanden ist, in der Portabilität. Es definiert eine Reihe von APIs, zu deren Implementierung .NET-Plattformen bereit sind. 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 Kosten der API-Oberfläche) zu mehreren Laufzeiten ausgeführt werden. Umgekehrt sind die .NET Core-Bibliotheksvorlagen vorhanden, um (auf Kosten der Kompatibilität) auf mehr API-Oberfläche zuzugreifen und eine Plattform anzugeben, für die eine ausführbare Datei erstellt werden soll.

502
Shaun Luttin

A .Net Core Class Library is built upon the .Net Standard. If you want to implement a library that is portable to the .Net Framework, .Net Core and Xamarin, choose a .Net Standard Library

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

. Net Core , Xamarin und .Net Framework kann daher als Flavours von identifiziert werden. Nettostandard

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 die Verwendung von . NET Standard anstelle von portablen Klassenbibliotheken .

Um MSDN als maßgebliche Quelle zu zitieren, soll . Net Standard eine Bibliothek sein , die sie alle regelt . Bilder sagen mehr als tausend Worte, und das Folgende wird die Dinge sehr klar 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)

enter image description here

2. Was die .Net Standard Library 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:

One Library to Rule them All

Für die Ungeduldigen:

  1. . NET Standard löst das Problem der Codefreigabe für .NET-Entwickler auf allen Plattformen, indem alle erwarteten und beliebten APIs in den von Ihnen benötigten Umgebungen bereitgestellt werden: Desktop-Anwendungen, mobile Apps und Spiele sowie Cloud-Dienste:
  2. . NET Standard ist eine Menge von APIs , die Alle .NET-Plattformen müssen implementieren. Dies vereinheitlicht die .NET-Plattformen und verhindert eine zukünftige Fragmentierung .
  3. . NET Standard 2.0 wird von . NET Framework ,. NET Core und Xamarin . Für . NET Core werden viele der angeforderten vorhandenen APIs hinzugefügt.
  4. . NET Standard 2.0 enthält ein Kompatibilitäts-Shim für . NET Framework Binärdateien. Erhöhen Sie die Anzahl der Bibliotheken, auf die Sie in Ihren .NET Standard-Bibliotheken verweisen können, erheblich.
  5. . NET Standard ersetzt Portable Class Libraries (PCLs) als Werkzeug Geschichte für die Erstellung von Multi-Plattform-.NET-Bibliotheken.

Um zu verstehen, auf welcher .NET-Plattform die höchste Version von .NET Standard ausgeführt werden kann, auf der Sie arbeiten möchten, klicken Sie hier .

Quellen: MSDN: Einführung des .Net-Standards

344
user919426

Die kurze Antwort wäre also:

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

. Net Framework 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 und in welchem ​​Profil sie installiert sind. Beispielsweise gibt es in universellen Windows-Apps andere APIs als im "normalen" Windows-Profil. Selbst unter Windows haben Sie möglicherweise das "Client" -Profil im Vergleich zum "vollständigen" Profil. 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 -Baugruppen verfügbar sein müssen. Eine für .NET Standard 1.0 geschriebene App sollte mit jeder Version von Framework, Core, Mono usw. kompiliert und ausgeführt werden können, die Unterstützung für die .NET Standard 1.0-Bibliothekssammlung bietet. Ähnliches gilt für .Net Standard 1.1, 1.5, 1.6, 2.0 usw. Solange die Laufzeit die von Ihrem Programm unterstützte 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 anderer Hersteller (z. B .: Elemente in NuGet) übernehmen können. Dies bedeutet jedoch, dass alle Abhängigkeiten, die Sie berücksichtigen, auch die Unterstützung Ihrer Version von .Net Standard umfassen müssen. .Net Standard entwickelt sich schnell weiter, ist aber immer noch neu genug und kümmert sich genug um einige der kleineren Laufzeitprofile, sodass sich diese Einschränkung möglicherweise erstickend anfühlt. (Beachten Sie anderthalb Jahre später: Dies beginnt sich zu ändern, und die neuesten .Net Standard-Versionen sind viel besser und mit mehr Funktionen ausgestattet.)

Andererseits sollte eine auf Standard ausgerichtete App in mehr Bereitstellungssituationen verwendet werden können , da sie theoretisch mit Core, Framework, Mono usw. Für ein Klassenbibliotheksprojekt, das eine breite Verbreitung sucht, ist das ein attraktives Versprechen. Für ein Klassenbibliotheksprojekt, das hauptsächlich für interne Zwecke verwendet wird, ist dies möglicherweise kein so großes Problem.

.Net Standard kann auch in Situationen nützlich sein, in denen das SysAdmin-Team 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 gegen .Net arbeiten möchte Framework in Visual Studio unter Windows.

66
Joel Coehoorn

.NET Framework und .NET Core sind beide Frameworks.

.NET Standard ist Standard (dh Spezifikation).

Sie können ausführbare Projekte (wie Konsolenanwendungen oder ASP.NET-Anwendungen) mit .NET Framework und .NET Core erstellen, jedoch nicht mit .NET Standard.

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

23
bside

Hoffe, dies wird helfen, die Beziehung zwischen .NET Standard API-Oberfläche und anderen .NET-Plattformen zu verstehen. Jede Schnittstelle stellt ein Zielframework dar und Methoden stellen Gruppen von APIs dar, 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

14
Mahbubur Rahman

Ein anderer Weg, um den Unterschied zu erklären, könnte in der Praxis bestehen, 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 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 die wichtigsten Desktop-Plattformen (Windows, Linux, Mac) als Ziel festlegen. 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, können jedoch alle/die meisten Plattformen ansprechen. Dank Xamarin können Sie auf Mobilgeräte und dank Mono/Unity sogar auf Spielekonsolen zugreifen.

In einer realen Anwendung müssen Sie möglicherweise alle verwenden. Ich habe zum Beispiel eine Point-of-Sale-Anwendung mit der folgenden Architektur entwickelt:

Gemeinsam genutzter Server und Client:

  • Eine .NET Standard-Bibliothek, die die Modelle meiner Anwendung verarbeitet.

Da es sich um eine .NET Standard-Bibliothek handelt, kann sie in jeder anderen Bibliothek verwendet werden.

Server Side (Web API):

  • Eine .NET-Standardbibliothek (kann auch Core sein), die alle Datenbankverbindungen verwaltet.

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

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

Clientseitig (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.

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

  • Ein Projekt für Xamarin Android und Xamarin IOS.

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

11
Dev Kevin

.NET Standard: Stellen Sie es sich als große Standardbibliothek vor. Wenn Sie dies als Abhängigkeit verwenden, können Sie nur Bibliotheken (.DLLs) erstellen, keine ausführbaren Dateien. Eine mit .NET-Standard als Abhängigkeit erstellte Bibliothek kann zu einem Xamarin.Android-, Xamarin.iOS- oder .NET Core Windows/OSX/Linux-Projekt hinzugefügt werden.

.NET Core: Betrachten Sie es als Fortsetzung des alten .NET-Frameworks, nur als OpenSource und einige Dinge sind noch nicht implementiert und andere sind veraltet. Es erweitert den .NET-Standard um zusätzliche Funktionen, läuft jedoch nur auf Desktops. Wenn Sie dies als Abhängigkeit hinzufügen, können Sie ausführbare Apps unter Windows, Linux und OSX erstellen. (Obwohl Konsole erstmal keine GUIs). Also .NET Core = .NET Standard + Desktop-spezifisches Zeug.
Auch UWP verwendet es und der neue ASP.NET-Kern verwendet es auch als Abhängigkeit.

10
sydd

Der .Net-Standard dient hauptsächlich der Verbesserung der Codefreigabe und der Bereitstellung konsistenterer APIs in jeder .Net-Implementierung.

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

8
ARP

The .NET Standard ist eine formale Spezifikation von .NET-APIs, die für alle .NET-Implementierungen verfügbar sein sollen.

The .NET Core ist ein kostenloses und Open-Source-verwaltetes Computer-Software-Framework für die Betriebssysteme Windows, Linux und macOS.

The .NET Framework ist ein Software-Framework, das hauptsächlich unter Microsoft Windows ausgeführt wird.

0
sajadre

Die obigen Antworten beschreiben möglicherweise das beste Verständnis für den Unterschied zwischen Netto-Core, Netto-Standard und Netto-Framwork. Daher möchte ich nur meine Erfahrungen teilen, wenn ich dies anstelle dessen auswä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 Windows Services-Hosting mit .NET Core nicht unterstützt.

Der nächste Grund ist, dass wir Active Report verwendet haben, das .NET Core nicht unterstützt. Aus diesem Grund 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 einen .NET-Standard entscheiden, müssen Sie sorgfältig überlegen, ob jede Klasse in der Bibliothek einfach und .NET-übergreifend sein soll (Kern, Framework, Standard).

Fazit:

  • .NET Standard für die Infrastrukturbibliothek und Shared Common. Diese Bibliothek kann von .NET Framework und .NET Core referenziert werden.
  • .NET Framework für nicht unterstützte Technologien wie Active Report und Windows Services (jetzt mit .NET 3.0).
  • Natürlich .NET Core für ASP.NET Core.

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

0
toannm