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

813

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?

Gigi
źródło
10
Brakowało jednego: Class Library (Portable). Rdzeń == framework, .NET Standard == przenośny.
Hans Passant
4
Był też jeden od Xamarina, ale te inne nie dodają żadnej wartości do pytania :)
Gigi
7
Cóż, robią. Podstawową ideą jest to, że zrezygnowali z przenośnego podejścia, zbyt mocno ucierpiało z powodu n! Problem z sposób zbyt wielu profili. Masz teraz 7 standardów do wyboru. Większość z nich nie jest w tej chwili przenośna :) .NETCore nie jest zrobione przez długi strzał, prawdopodobnie zajmuje kolejne dwa lata od klipu, który jadą.
Hans Passant
12
OP powiedział „co najmniej 3 różne typy”. Post był dokładny.
Dan Friedman,
1
Byłem zdezorientowany nazwaniem rdzenia, który nie jest podzbiorem rdzenia ani standardowej, ani szkieletowej platformy. Regularnie widzimy też ASP związane z .Net Core. Jest to również bardzo mylące ...
Alexis Pautrot

Odpowiedzi:

610

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.

Shaun Luttin
źródło
2
Bardzo dobra odpowiedź. Dodatkowe pytanie (dotyczy tego pytania : dlaczego model aplikacji jest niezbędny do uruchomienia testów jednostkowych? Nigdy nie było tak w przeszłości, gdy używaliśmy bibliotek klas nieoperacyjnych do przechowywania kolekcji testów jednostkowych.
Gigi
3
Zaktualizowałem swoją odpowiedź na powiązane pytanie. TL; DR; W przeszłości biblioteki klas były ukierunkowane na pełną platformę, która obejmuje model aplikacji.
Shaun Luttin
Zapomniałeś o objęciu biblioteki klas (.NET Framework), czy jest kompatybilny z .NET Standard i .NET Core?
Tomas
8
Ten schemat naprawdę mi pomógł.
jpaugh
1
@BerBar Pierwotne pytanie dotyczyło różnicy między .NET Standard a .NET Core. Dlatego pominąłem szczegóły dotyczące różnych platform, ponieważ między platformami nie ma różnicy między rdzeniem a standardem. Celowo utrzymałem moją odpowiedź na pierwotne pytanie.
Shaun Luttin
396

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)

Wpisz opis zdjęcia tutaj

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:

Jedna biblioteka do rządzenia nimi wszystkimi

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

użytkownik919426
źródło
2
ASP.NET Core jest nieco źle umieszczony w tej grafice, ponieważ można go używać z pełnym .NET Framework, nie tylko .NET Core, ponieważ w rzeczywistości jest przeznaczony dla .NET Standard.
Neme,
2
Ale możesz utworzyć aplikację ASP.NET Core z pełnym .NET Framework - ASP.NET Core naprawdę należy do tej samej warstwy, co .NET Standard. Nie ogranicza się tylko do .NET Core.
Neme,
1
@Neme Po pierwsze, tak. Net Core może obejmować biblioteki .Net Framework, ale traci możliwość ponownego wykorzystania na różnych platformach (tylko w systemie Windows - nie * nix lub OSX lub ponownego użycia w Xamarin). Sytuacja, która została zaspokojona, biorąc pod uwagę, że wiele osób ma i chce ponownie wykorzystać istniejące biblioteki napisane w całości. Framework Framework bez zainteresowania korzyściami dla różnych platform (na poziomie systemu operacyjnego i na poziomie modelu aplikacji) ... Jeśli nadal czujesz, że jestem źle, być może możesz kłócić się z Microsoftem, który jest autorem tych obrazów ... :-)
user919426
3
Nie mówię o połączeniu .NET Core i .NET Framework. Chodzi mi o to, że ASP.NET Core w ogóle nie jest zależny od .NET Core, pomimo nazwy. Jest napisany jako biblioteka skierowana do .NET Standard, dlatego możesz go używać wszędzie tam, gdzie możesz używać .NET Standard. Tak, popełnili błąd na tym obrazie.
Neme,
2
@OgrishMan Nie można utworzyć pliku wykonywalnego w .Net Standard . Może to być tylko biblioteka klas, do której można odwoływać się za pomocą innego kodu wykonawczego. Nie ma czasu działania .
user919426
91

Krótka odpowiedź brzmiałaby:

IAnimal == .NetStandard (General)
ICat == .NetCore (Less General)
IDog == .NetFramework (Specific / oldest and has the most features)
Joe
źródło
26
@ Joe.wang, jak widzę, źle, że zaburza relacje między .NET Core i .NET Framework. Jeśli .NET Core jest ptakiem, to .NET Framework nie może być orłem (może kot jest bardziej odpowiedni).
Lex Li
8
@LexLi ma rację, to zabrudza wody. .NET Framework nie jest podtypem .NET Core.
Eric Eskildsen,
6
może się to wydawać nieco fantazyjne, ale nie
dokładne
3
Oryginalny komentarz @Joe brzmiał bardziej precyzyjnie. zredagowana odpowiedź przez społeczność spowodowała zamieszanie
Nandun
7
Psy mają więcej funkcji niż koty? Nop :)
hrzafer
71

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

Joel Coehoorn
źródło
1
Mimo dobrego przeglądu tego, czym są .NET Core i .NET Standard, ta odpowiedź nie odpowiada na pytanie o biblioteki klas ukierunkowane na każdą z nich.
Gigi,
6
Jeśli to jest twój cel, pytanie musi zostać zamknięte jako „niejasne, o co pytasz”, ponieważ zawsze będzie zbyt wiele specyfiki sytuacyjnych, które grają w środowisku danej osoby, abyśmy mogli powiedzieć ci, co robić lub jako „Zbyt szeroki”, jeśli pytasz o ogólny przypadek. Wszystko, co możemy zrobić, to podać informacje o produktach, abyś mógł zostać poinformowany o podjęciu własnej decyzji.
Joel Coehoorn
Oczywiście tak nie jest, ponieważ inny dokładnie odpowiedział na pytanie. Moje pytanie dotyczyło bibliotek klas. Twoja odpowiedź dotyczyła ram.
Gigi
29

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

Strona B
źródło
20

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

Mahbubur Rahman
źródło
17

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.

Dev Kevin
źródło
2
Myślę, że jest to lepsza odpowiedź, ponieważ obejmuje rzeczywisty świat.
J Weezy,
12

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

Peter Mortensen
źródło
8

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

ARP
źródło
2

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/

toannm
źródło
@Gigi Proszę uważnie przeczytać moją odpowiedź, powiedziałem, że to było. Program ASP.NET Core obsługuje platformę .NET Framework od wersji 2.0 powyżej. Moja odpowiedź to historia, gdy masz do czynienia z wieloma wersjami platformy .NET. Więc nie rozumiem, dlaczego masz głos negatywny, gdy nie rozumiesz poprawnie sytuacji.
toannm
Dzięki za odpowiedź - przeczytałem twoją odpowiedź i przeczytałem część, w której odwołałeś się do .NET Core 1.0. Jednak nie wziąłem tego za warunek wstępny interpretacji twoich wniosków, co w przeciwnym razie wprowadzałoby w błąd ludzi czytających przy obecnej wersji. Ponadto wygląda na to, że mój komentarz został wysunięty przez policję Stack Overflow, co jest wstydem, do którego przyzwyczaiłem się na tej stronie.
Gigi
0

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

Fabio Panzironi
źródło
0

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

Ömer Özkan
źródło
Twoja odpowiedź nie jest w pełni związana z pytaniem. proszę o poprawienie
Avid Programmer