Dziś ogłaszamy, że kolejną wersją po .NET Core 3.0 będzie .NET 5. Będzie to kolejna duża premiera z serii .NET.
W przyszłości będzie tylko jeden .NET, dzięki któremu będziesz mógł tworzyć Windows, Linux, macOS, iOS, Android, tvOS, watchOS i WebAssembly, między innymi.
Wprowadzamy nowe API .NET, funkcje wykonawcze i językowe w .NET 5.
Zaczynając od projektu .NET Core, dodaliśmy do platformy około pięćdziesięciu tysięcy API .NET Framework. .NET Core 3.0 wypełnia większość pozostałych luk funkcjonalnych .NET Framework 4.8, obsługując Windows Forms, WPF i Entity Framework 6. .NET 5 rozwija tę pracę, wykorzystując najlepsze cechy .NET Core i Mono do tworzenia platformy. Możesz go używać do całego nowoczesnego kodu .NET.
Planujemy wydać .NET 5 w listopadzie 2020 roku i uruchomić pierwszą wersję preview w pierwszej połowie 2020 roku. Będzie wspierany w przyszłych aktualizacjach dla Visual Studio 2019, Visual Studio na Mac oraz Visual Studio Code.
.NET 5 = .NET Core vNext
.NET 5 to kolejny krok w .NET Core. Projekt ma na celu poprawę . NET:
- Stwórz runtime i framework .NET, który można używać wszędzie, z jednolitym zachowaniem w czasie działania i doświadczeniem deweloperskim.
- Dzięki pełnej korzyści z .NET Core, . NET Framework, Xamarin, oraz Mono, aby rozszerzyć możliwości .NET.
- Budując produkt na bazie jednego kodu, deweloperzy (Microsoft i społeczność) mogą współpracować i rozwijać się razem, aby ulepszać wszystkie scenariusze.
Ten nowy projekt i kierunek to ważny punkt zwrotny dla .NET. W .NET 5 Twój kod i pliki projektowe będą takie same, niezależnie od rodzaju aplikacji, którą tworzysz. Każda aplikacja ma dostęp do tych samych funkcji runtime, API i języka. Zawiera także poprawy wydajności CoreFX, które są wprowadzane niemal codziennie.
Wszystko, co kochasz w .NET Core, będzie istnieć dalej:
- Open source i zorientowany na społeczność na GitHubie.
- Implementacja wieloplatformowa.
- Wspieraj wykorzystanie funkcji specyficznych dla platformy, takich jak formularze Windows i WPF na Windows, oraz natywne przypisania dla każdej natywnej platformy od Xamarin.
- Wysoka wydajność.
- Instaluj obok siebie.
- Małe pliki projektów (w stylu SDK).
- Kompatybilny z interfejsami wiersza poleceń (CLI).
- Visual Studio, Visual Studio na Maca oraz integracja z Visual Studio Code.
Są też nowe rzeczy:
- Będziesz miał więcej opcji dla swojego doświadczenia w czasie rzeczywistym (więcej o tym poniżej).
- Interoperacyjność Java będzie dostępna na wszystkich platformach.
- Wiele systemów operacyjnych będzie wspierać interoperacyjność Objective-C i Swift.
- CoreFX zostanie rozszerzony o wsparcie ahead-of-time (AOT) dla .NET, mniejszy zasięg oraz wsparcie dla większej liczby systemów operacyjnych.
We wrześniu tego roku wydamy .NET Core 3.0, w listopadzie 2020 .NET 5, a następnie planujemy wydać główną wersję . NET:
Pominęliśmy wersję 4, ponieważ mogłaby zdezorientować użytkowników zaznajomionych z .NET Frameworkiem, który istnieje od dawna w serii 4.x. Dodatkowo chcemy jasno zakomunikować, że .NET 5 to przyszłość platformy .NET. Nazwanie go .NET 5 czyni to najwyższą wersję, jaką kiedykolwiek wydaliśmy.
Korzystamy także z okazji, by uprościć nazewnictwo. Uważamy, że jeśli tylko jeden .NET jest najlepszy, nie potrzebujemy określenia wyjaśniającego jak "Core". Skrócona nazwa jest uproszczeniem i przekazuje również informację, że .NET 5 ma jednolitą funkcjonalność i zachowanie. Oczywiście możesz nadal używać nazwy ".NET Core", jeśli chcesz.
Doświadczenie w czasie rzeczywistym
Mono to oryginalna wieloplatformowa implementacja .NET. Początkowo był otwartą alternatywą dla .NET Framework, a wraz z popularnością urządzeń iPhone/iOS i Android przeszedł na specyficzne dla urządzeń mobilnych. Mono to runtime używany jako część Xamarin.
CoreCLR to środowisko uruchomieniowe używane jako część .NET Core. Jest głównie wykorzystywany do obsługi aplikacji chmurowych, w tym największej usługi Microsoftu, a obecnie jest również wykorzystywany w aplikacjach desktopowych na Windows, IoT oraz uczeniu maszynowym.
Podsumowując, środowiska uruchomieniowe .NET Core i Mono mają wiele podobieństw (w końcu oba są runtime'ami .NE), ale mają też cenne, unikalne cechy. Ma to dużo sensu, by umożliwić wybór doświadczenia w czasie rzeczywistym, które chcesz. Robimy CoreCLR i Mono wymiennymi ze sobą. Zrobimy to tak prosto, jak zbudowanie przełącznika, aby wybrać spośród różnych opcji w czasie rzeczywistym.
Poniższe sekcje opisują główny obszar, na którym planujemy się zająć w .NET 5. Dają one jasną perspektywę na to, jak planujemy rozwijać te dwa runtime'y indywidualnie i razem.
Wysoka przepustowość i wysoka wydajność
Od początku .NET opierał się na kompilatorach just-in-time (JIT) do konwersji kodu języka pośredniego (IL) na zoptymalizowany kod maszynowy. Od tego czasu zbudowaliśmy wiodący w branży zarządzany runtime oparty na JIT, który ma bardzo wysoką przepustowość i poprawia doświadczenie deweloperów, czyniąc programowanie szybkim i prostym.
JIT jest idealny do długotrwałych scenariuszy chmurowych i klientowych. Są w stanie generować kod skonfigurowany dla konkretnych maszyn, w tym konkretne instrukcje CPU. JIT może także generować metody w czasie działania, co przyspiesza JIT, a jednocześnie pozwala generować wysoce zoptymalizowane wersje kodu, jeśli stanie się on często używany.
Nasze wysiłki, by ASP.NET Core działał szybciej na benchmarku Techpower, są świetnym przykładem siły JIT i naszej inwestycji w CoreCLR. Nasze wysiłki na rzecz wzmocnienia .NET Core dla kontenerów są również dowodem na zdolność środowiska uruchomieniowego do dynamicznego dostosowywania się do ograniczonych środowisk.
Narzędzia deweloperskie to kolejny świetny przykład, jak JIT jest naprawdę świetny, jak narzędzia do monitorowania dotnet czy edycja i kontynuacja. Narzędzia często muszą kompilować i ładować kod wielokrotnie w jednym procesie bez restartu, i to bardzo szybko.
Programiści korzystający z .NET Core lub .NET Framework polegają głównie na JIT. Dlatego doświadczenie powinno być znajome.
Domyślne doświadczenie w większości scenariuszy pracy .NET 5 będzie korzystało z środowiska uruchomieniowego CoreCLR opartego na JIT. Dwa godne uwagi wyjątki to iOS i klient Blazor (web assembly), ponieważ oba wymagają natywnej kompilacji z wyprzedzeniem (AOT).
Szybki start, mały rozmiar i niskie zużycie pamięci
Większość projektu Mono skupia się na urządzeniach mobilnych i konsolach. Kluczową cechą i efektem projektu jest kompilator .NET AOT oparty na wiodącym w branży projekcie kompilatora LLVM. Kompilator Mono AOT pozwala na wbudowanie kodu .NET w natywny plik wykonywalny, który może działać na komputerze, podobnie jak kod w C++. Aplikacje skompilowane przez AOT mogą działać efektywnie w mniejszych lokalizacjach i wymieniać przepustowość na potrzeby uruchomienia, gdy jest to potrzebne.
Projekt Blazor już korzysta z Mono AOT. Będzie to jeden z pierwszych projektów przechodzących na .NET 5. Używamy tego jako jednej z opcji, by udowodnić ten plan.
Istnieją dwa typy rozwiązań AOT:
- Wymaga rozwiązania skompilowanego w 100% AOT.
- Większość kodu to rozwiązania kompilowane przez AOT, ale JIT lub interpretery mogą być używane dla wzorców kodu, które nie są przyjazne dla AOT (np. generyki). Mono AOT obsługuje oba przypadki. Apple wymaga pierwszego AOT dla iOS i niektórych konsol ze względów bezpieczeństwa. Druga metoda jest lepsza, ponieważ oferuje zalety AOT i unika niektórych wad.
.NET Native to nasz kompilator AOT dla aplikacji Windows UWP i jest także przykładem pierwszego wymienionego powyżej typu AOT. W tej konkretnej implementacji ograniczamy API .NET oraz funkcje, z których możesz korzystać. Z tego doświadczenia nauczyliśmy się, że rozwiązania AOT muszą obejmować wszystkie aspekty API i wzorców .NET.
Kompilacja AOT jest nadal wymagana na iOS, webaassembly i niektórych konsolach. W przypadku aplikacji wymagających szybszego startu lub niskiego obciążenia projektowego, kompilacja AOT będzie opcją.
Narodziny projektu
Projekt rozpoczęliśmy w grudniu 2018 roku z zespołem technicznym w Bostonie. Liderzy projektowi z zespołu .NET (Mono/Xamarin i .NET Core) oraz Unity przedstawili różnorodne możliwości techniczne i kierunki architektoniczne.
Teraz realizujemy ten projekt jako zespół z zestawem wyników. Od grudnia poczyniliśmy duże postępy w wielu projektach:
- Zdefiniowana jest minimalna warstwa definiująca środowisko wykonawcze <-> zarządzanej warstwy kodu, z celem osiągnięcia >99% publicznego kodu CoreFX.
- MonoVM może teraz korzystać z CoreFX i jego bibliotek klas.
- Uruchom wszystkie testy CoreFX na MonoVM z implementacją CoreFX.
- Uruchamiam ASP.NET aplikacje Core 3.0 z MonoVM.
- Uruchom MonoDevelop na CoreCLR, a następnie Visual Studio na Maca.
Migruj do pojedynczej . Implementacja .NET rodzi ważne pytania: Jaki będzie docelowy framework? Czy reguły kompatybilności pakietów NuGet są takie same? Jakie obciążenia powinno obsługiwać SDK .NET 5? Jak zaprogramować dla konkretnej architektury? Czy nadal potrzebujemy standardu .NET?
Obecnie pracujemy nad tymi kwestiami i wkrótce udostępnimy dokument projektowy, który Państwo przeczytają i udzielą Wam opinii.
Epilog
Projekt .NET 5 to ważny i ekscytujący nowy kierunek dla .NET. Zobaczysz, że .NET stanie się prostszy, ale też z szerszym zakresem funkcji i użyteczności. Wszystkie nowe rozwiązania i funkcje będą częścią .NET 5, w tym nowe wersje C#.
Widzimy świetlaną przyszłość, w której można używać tych samych API i języków .NET do celowania w szeroki zakres typów aplikacji, systemów operacyjnych i architektur krzemowych. W Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps czy w wierszu poleceń łatwo jest zmienić konfigurację budowania, aby tworzyć różne aplikacje.
Oryginalny link:Logowanie do linku jest widoczne.
|
Opublikowano 07.05.2019 09:41:27
|
|
|
|
