Jaka jest różnica między typami projektów .NET Core i .NET Standard Class Library?

W programie Visual Studio istnieją co najmniej 3 różne typy bibliotek klas, które można utworzyć:

• Biblioteka klas (.NET Framework)
• Biblioteka klas (.NET Standard)
• Biblioteka klas (.NET Core)

Podczas gdy pierwszy jest tym, z którego korzystamy od lat, głównym problemem jest to, kiedy używam typów bibliotek klas .NET Standard i .NET Core. Niedawno mnie to ugryzło, gdy próbowałem obsługiwać różne wersje frameworka i tworzyć projekt testu jednostkowego .

Więc jaka jest różnica między Biblioteką klas (.NET Standard) a Biblioteką klas (.NET Core) , dlaczego istnieją obie i kiedy powinniśmy używać jednej z nich?

Kiedy powinniśmy stosować jeden na drugim?

Decyzja jest kompromisem między zgodnością a dostępem do interfejsu API.

Użyj biblioteki .NET Standard, jeśli chcesz zwiększyć liczbę aplikacji, które będą kompatybilne z twoją biblioteką, i nie przeszkadza ci zmniejszenie powierzchni interfejsu API .NET, do którego biblioteka może uzyskać dostęp.

Użyj biblioteki .NET Core, jeśli chcesz zwiększyć obszar .NET API, do którego biblioteka może uzyskać dostęp, i możesz pozwolić, aby tylko aplikacje .NET Core były kompatybilne z twoją biblioteką.

Na przykład biblioteka kierowana na .NET Standard 1.3 będzie kompatybilna z aplikacjami ukierunkowanymi na .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0 i dowolną inną platformą obsługującą .NET Standard 1.3. Biblioteka nie będzie jednak mieć dostępu do niektórych części interfejsu API .NET. Na przykład Microsoft.NETCore.CoreCLRpakiet jest zgodny z .NET Core, ale nie z .NET Standard.

Jaka jest różnica między biblioteką klas (.NET Standard) a biblioteką klas (.NET Core)?

Sekcja Frameworki oparte na pakiecie opisuje różnicę.

Zgodność: biblioteki docelowe .NET Standard będą działać na dowolnym środowisku wykonawczym zgodnym z .NET Standard, takim jak .NET Core, .NET Framework, Mono / Xamarin. Z drugiej strony biblioteki docelowe .NET Core mogą działać tylko w środowisku uruchomieniowym .NET Core.

Obszar API: Standardowe biblioteki .NET są wyposażone we wszystko, NETStandard.Librarya biblioteki .NET Core mają wszystko Microsoft.NETCore.App. Ta ostatnia zawiera około 20 dodatkowych bibliotek, z których niektóre możemy dodać ręcznie do naszej biblioteki .NET Standard (np. System.Threading.Thread), A niektóre z nich nie są kompatybilne z .NET Standard (np. Microsoft.NETCore.CoreCLR).

Ponadto biblioteki .NET Core określają środowisko wykonawcze i są dostarczane z modelem aplikacji. Jest to ważne na przykład, aby biblioteki klas testów jednostkowych mogły być uruchamiane.

Dlaczego oba istnieją?

Ignorując biblioteki przez chwilę, przyczyną istnienia .NET Standard jest przenośność; definiuje zestaw interfejsów API, które platformy .NET zgadzają się wdrożyć. Każda platforma, która implementuje .NET Standard, jest kompatybilna z bibliotekami ukierunkowanymi na ten .NET Standard. Jedną z tych kompatybilnych platform jest .NET Core.

Wracając do bibliotek, szablony bibliotek .NET Standard istnieją do uruchamiania w wielu środowiskach wykonawczych (kosztem powierzchni interfejsu API). I odwrotnie, istnieją szablony bibliotek .NET Core, aby uzyskać dostęp do większej powierzchni API (kosztem zgodności) i określić platformę, na której można zbudować plik wykonywalny.

Oto interaktywna matryca pokazująca, które .NET Standard obsługuje, które implementacje .NET i ile powierzchni API jest dostępne.

NET Rdzeń Class Library jest zbudowany na standardzie NET . Jeśli chcesz wdrożyć biblioteki, który jest przenośny do .NET Framework ,. .NET Core i Xamarin , wybierz bibliotekę .NET Standard Library

.NET Core ostatecznie wdroży .NET Standard 2 (podobnie jak Xamarin i .NET Framework )

NET rdzenia , Xamarin i .NET Framework może być zatem uznana za smaków z .NET Standardu

Aby zapewnić przyszłym aplikacjom współdzielenie i ponowne użycie kodu, wolisz wdrożyć biblioteki .NET Standard.

Microsoft zaleca również stosowanie standardu .NET zamiast bibliotek klas przenośnych .

Aby podać MSDN jako wiarygodne źródło, .NET Standard ma być jedną biblioteką, aby rządzić nimi wszystkimi . Ponieważ zdjęcia są warte tysiąca słów, poniższe wyjaśnią to bardzo wyraźnie:

1. Twój obecny scenariusz aplikacji (fragmentaryczny)

Podobnie jak większość z nas, prawdopodobnie znajdujesz się w poniższej sytuacji: (.NET Framework, Xamarin, a teraz aplikacje o smaku .NET Core)

2. Co umożliwi Ci biblioteka standardowa .NET (zgodność między różnymi środowiskami)

Implementacja biblioteki standardowej .NET umożliwia udostępnianie kodu we wszystkich tych różnych odmianach:

Dla niecierpliwych:

1. .NET Standard rozwiązuje problem współdzielenia kodu dla programistów .NET na wszystkich platformach, oferując wszystkie interfejsy API, których oczekujesz i których kochasz we wszystkich potrzebnych środowiskach: aplikacje komputerowe, aplikacje i gry mobilne oraz usługi w chmurze:
2. .NET Standard to zestaw interfejsów API, które muszą implementować wszystkie platformy .NET . To ujednolica platformy .NET i zapobiega fragmentacji w przyszłości .
3. Standardowy .NET 2.0 będą realizowane przez .NET Framework ,. NET Core i Xamarin . W przypadku .NET Core spowoduje to dodanie wielu istniejących interfejsów API, o które poproszono.
4. .NET Standard 2.0 zawiera podkładkę kompatybilności dla plików binarnych .NET Framework , znacznie zwiększając zestaw bibliotek, do których można odwoływać się z bibliotek .NET Standard.
5. .NET Standard zastąpi przenośne biblioteki klas (PCL) jako narzędzie do budowania wieloplatformowych bibliotek .NET.

Aby zapoznać się z tabelą pomagającą zrozumieć, na którą najwyższą wersję .NET Standard można kierować, na podstawie platform .NET, na których zamierzasz uruchomić, przejdź tutaj .

Źródła: MSDN: Przedstawiamy .NET Standard

Krótka odpowiedź brzmiałaby:

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

.NET i .NET Core to dwie różne implementacje środowiska wykonawczego .NET. Zarówno Core, jak i Framework (ale przede wszystkim Framework) mają różne profile, które obejmują większe lub mniejsze (lub po prostu różne) wybory wielu interfejsów API i zestawów, które Microsoft stworzył dla .NET, w zależności od tego, gdzie są zainstalowane i w jakim profilu.

Na przykład niektóre aplikacje API są dostępne w aplikacjach Universal Windows niż w „normalnym” profilu Windows. Nawet w systemie Windows możesz mieć profil „Klient” w porównaniu z profilem „Pełny”. Ponadto istnieją inne implementacje (takie jak Mono ), które mają własne zestawy bibliotek.

.NET Standard to specyfikacja, dla której zestawy bibliotek i zestawów API muszą być dostępne. Aplikacja napisana dla .NET Standard 1.0 powinna być w stanie kompilować i działać z dowolną wersją Framework, Core, Mono itp., Która reklamuje wsparcie dla kolekcji bibliotek .NET Standard 1.0. Podobnie jest w przypadku .NET Standard 1.1, 1.5, 1.6, 2.0 itd. Tak długo, jak środowisko wykonawcze zapewnia obsługę wersji Standardu docelowej dla Twojego programu, Twój program powinien tam działać.

Projekt ukierunkowany na wersję Standardu nie będzie mógł korzystać z funkcji, które nie są uwzględnione w tej wersji standardu. Nie oznacza to, że nie możesz przyjmować zależności od innych zestawów lub interfejsów API opublikowanych przez innych dostawców (np .: elementy w NuGet). Oznacza to jednak, że wszelkie zależności, które bierzesz, muszą również obejmować obsługę Twojej wersji .NET Standard. .NET Standard ewoluuje szybko, ale wciąż jest wystarczająco nowy i dba o niektóre mniejsze profile środowiska wykonawczego, aby ograniczenie to było duszne. (Uwaga półtora roku później: zaczyna się to zmieniać, a najnowsze wersje .NET Standard są znacznie ładniejsze i pełniej wyposażone).

Z drugiej strony, aplikacja ukierunkowana na Standard powinna móc być używana w większej liczbie sytuacji wdrożeniowych, ponieważ teoretycznie może działać z Core, Framework, Mono itp. W przypadku projektu biblioteki klasowej, który szuka szerokiej dystrybucji, jest to atrakcyjna obietnica . W przypadku projektu biblioteki klas wykorzystywanego głównie do celów wewnętrznych może to nie stanowić większego problemu.

.NET Standard może być również przydatny w sytuacjach, gdy zespół administratora systemu chce przejść z ASP.NET w systemie Windows na ASP.NET dla .NET Core w systemie Linux z powodów filozoficznych lub kosztowych, ale zespół programistów chce kontynuować pracę. NET Framework w Visual Studio w systemie Windows.

.NET Framework i .NET Core są platformami.

.NET Standard jest standardem (innymi słowy specyfikacją).

Możesz utworzyć projekt wykonywalny (np. Aplikację konsolową lub aplikację ASP.NET) za pomocą .NET Framework i .NET Core, ale nie za pomocą .NET Standard.

Za pomocą .NET Standard można tworzyć tylko projekty bibliotek klas, których nie można wykonać samodzielnie i do których powinien odwoływać się inny projekt wykonywalny .NET Core lub .NET Framework.

Mam nadzieję, że pomoże to zrozumieć związek między powierzchnią interfejsu .NET Standard API a innymi platformami .NET . Każdy interfejs reprezentuje docelową strukturę, a metody reprezentują grupy interfejsów API dostępnych w tej docelowej strukturze.

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
}
}

Źródło

Innym sposobem wyjaśnienia różnicy mogą być przykłady z prawdziwego świata, ponieważ większość z nas śmiertelników używa do tego celu istniejących narzędzi i struktur (Xamarin, Unity itp.).

Tak więc, dzięki .NET Framework masz wszystkie narzędzia .NET do pracy, ale możesz celować tylko w aplikacje Windows (UWP, Winforms, ASP.NET itp.). Ponieważ .NET Framework jest zamkniętym źródłem, nie ma wiele do zrobienia.

Dzięki .NET Core masz mniej narzędzi, ale możesz celować w główne platformy pulpitu (Windows, Linux, Mac). Jest to szczególnie przydatne w aplikacjach ASP.NET Core, ponieważ możesz teraz hostować Asp.net w systemie Linux (niższe ceny hostingu). Teraz, ponieważ .NET Core był open source, technicznie możliwe jest tworzenie bibliotek dla innych platform. Ale ponieważ nie ma ram, które to obsługują, nie sądzę, że to dobry pomysł.

Dzięki .NET Standard masz jeszcze mniej narzędzi, ale możesz kierować reklamy na wszystkie / większość platform. Możesz celować w Mobile dzięki Xamarin, a nawet w konsole do gier dzięki Mono / Unity. Aktualizacja: Możliwe jest również atakowanie klientów internetowych za pomocą platformy UNO i Blazora (chociaż obecnie oba są nieco eksperymentalne).

W rzeczywistej aplikacji może być konieczne użycie wszystkich z nich. Na przykład opracowałem aplikację w punkcie sprzedaży o następującej architekturze:

Udostępniono zarówno serwer, jak i klienta:

• Biblioteka .NET Standard, która obsługuje modele mojej aplikacji.
• Biblioteka .NET Standard, która obsługuje sprawdzanie poprawności danych wysyłanych przez klientów.

Ponieważ jest to biblioteka .NET Standard, może być używana w każdym innym projekcie (klient i serwer).

Zaletą jest również sprawdzanie poprawności w standardowej bibliotece .NET, ponieważ mogę być pewien, że ta sama weryfikacja zostanie zastosowana na serwerze i kliencie. Serwer jest obowiązkowy, a klient opcjonalny i przydatny w celu zmniejszenia ruchu.

Po stronie serwera (Web API):

• Biblioteka .NET Standard (może być również Core), która obsługuje wszystkie połączenia z bazą danych.

• Projekt .NET Core, który obsługuje interfejs API Rest i korzysta z biblioteki bazy danych.

Ponieważ jest to opracowane w .NET Core, mogę hostować aplikację na serwerze Linux.

Po stronie klienta (MVVM z WPF + Xamarin.Forms Android / IOS):

• Biblioteka .NET Standard, która obsługuje połączenie API klienta.

• Biblioteka .NET Standard, która obsługuje logikę ViewModels. Używany we wszystkich widokach.

• Aplikacja WPF .NET Framework, która obsługuje widoki WPF dla aplikacji systemu Windows. Aktualizacja: aplikacje WPF mogą być teraz .NET core, chociaż obecnie działają tylko w systemie Windows. AvaloniaUI jest dobrą alternatywą do tworzenia aplikacji GUI na komputery stacjonarne dla innych platform.

• Biblioteka .NET Standard, która obsługuje widoki formularzy Xamarin.

• Projekt Xamarin Android i Xamarin IOS.

Widzisz więc, że po stronie klienta aplikacji jest duża zaleta, ponieważ mogę ponownie używać obu bibliotek .NET Standard (API klienta i ViewModels) i tworzyć widoki bez logiki dla aplikacji WPF, Xamarin i IOS.

.NET Standard: Pomyśl o tym jak o dużej standardowej bibliotece. Używając tego jako zależności, możesz tworzyć tylko biblioteki (.DLLs), a nie pliki wykonywalne. Bibliotekę wykonaną w standardzie .NET jako zależność można dodać do projektu Xamarin.Android, Xamarin.iOS, .NET Core Windows / OS X / Linux.

.NET Core: Pomyśl o tym jako o kontynuacji starego frameworku .NET, po prostu jest to open source, a niektóre rzeczy nie są jeszcze zaimplementowane, a inne przestarzałe. Rozszerza standard .NET o dodatkowe funkcje, ale działa tylko na komputerach stacjonarnych . Dodając to jako zależność, możesz tworzyć działające aplikacje w systemach Windows, Linux i OS X. (Chociaż konsola jest tylko na razie, nie ma GUI). Tak więc .NET Core = .NET Standard + rzeczy specyficzne dla pulpitu.

Również UWPUżywa go , a nowy program ASP.NET Core używa go również jako zależności.

.NET Standard istnieje głównie po to, by usprawnić współdzielenie kodu i zwiększyć spójność interfejsów API w każdej implementacji .NET.

Podczas tworzenia bibliotek możemy mieć cel jako .NET Standard 2.0, aby utworzona biblioteka była kompatybilna z różnymi wersjami .NET Framework, w tym .NET Core, Mono itp.

Powyższe odpowiedzi mogą opisywać najlepsze zrozumienie różnicy między rdzeniem sieci, standardem sieci i ramą sieci, więc chcę po prostu podzielić się swoim doświadczeniem, wybierając to.

W projekcie, który musisz łączyć między .NET Framework, .NET Core i .NET Standard. Na przykład w momencie, gdy budujemy system z .NET Core 1.0, nie ma obsługi hostingu Windows Services z .NET core.

Kolejnym powodem jest to, że korzystamy z Active Report, który nie obsługuje .NET Core. Dlatego chcemy zbudować bibliotekę infrastruktury, która może być używana zarówno dla .NET Core (asp.net core), jak i Windows Service and Reporting (.NET Framework) -> Właśnie dlatego wybraliśmy .NET Standard dla tego rodzaju bibliotek. Wybór standardu .NET oznacza, że ​​musisz dokładnie rozważyć każdą klasę w bibliotece, która powinna być prosta i przekrojowa .NET (core, framework, standard).

Wniosek:

• .NET Standard dla biblioteki infrastruktury i współużytkowany. Do tej biblioteki mogą odwoływać się .NET Framework i .NET Core.
• .NET Framework dla nieobsługiwanych technologii takich jak Active Report, Windows Services (teraz z .NET 3.0 obsługuje).
• Oczywiście .NET Core dla ASP.NET Core.

Microsoft właśnie ogłosił .NET 5: https://devblogs.microsoft.com/dotnet/introducing-net-5/

Aplikacja .NET Framework Windows Form, ASP.NET i WPF musi zostać opracowana przy użyciu biblioteki .NET Framework

Aplikacja .NET Standard Xamarin, IOs i MAC OSx musi zostać opracowana przy użyciu biblioteki .NET Standard

Platforma .NET Core Universal Windows Platform (UWP) i Linux muszą zostać opracowane przy użyciu biblioteki .NET Core. Interfejs API jest zaimplementowany w C ++ i możesz używać języków C ++, VB.NET, C #, F # i Javascript .NET

Biblioteka klas .Net Core jest oparta na standardzie .Net. Jeśli chcesz zaimplementować bibliotekę przenośną dla .Net Framework, .Net Core i Xamarin, wybierz bibliotekę standardową .Net