Сьогодні ми оголошуємо, що наступним релізом після .NET Core 3.0 буде .NET 5. Це буде наступний великий реліз у серії .NET.
У майбутньому буде лише один .NET, на якому ви зможете розробляти Windows, Linux, macOS, iOS, Android, tvOS, watchOS і WebAssembly, серед інших.
Ми впроваджуємо нові .NET API, функції виконання та мовні особливості у .NET 5.
Починаючи з проєкту .NET Core, ми додали близько п'ятдесяти тисяч API .NET Framework до платформи. .NET Core 3.0 заповнює більшість залишкових прогалин у функціях .NET Framework 4.8, підтримуючи Windows Forms, WPF та Entity Framework 6. .NET 5 розвиває цю роботу, використовуючи найкращі можливості .NET Core і Mono для створення платформи. Ви можете використовувати його для всього сучасного .NET-коду.
Ми плануємо випустити .NET 5 у листопаді 2020 року та запустити перший прев'ю у першій половині 2020 року. Він буде підтримуватися в майбутніх оновленнях для Visual Studio 2019, Visual Studio для Mac та Visual Studio Code.
.NET 5 = .NET Core vNext
.NET 5 — це наступний крок у .NET Core. Проєкт має на меті покращити . NET:
- Створіть .NET runtime і фреймворк, які можна використовувати будь-де, з уніфікованою поведінкою під час виконання та досвідом розробника.
- Повністю використовуючи .NET Core, . NET Framework, Xamarin і Mono для розширення можливостей .NET.
- Створюючи продукт на основі єдиної кодової бази, розробники (Microsoft і спільнота) можуть працювати разом і розширювати його для покращення всіх сценаріїв.
Цей новий проєкт і напрямок є важливим переломним моментом для .NET. З .NET 5 ваш код і файли проєкту будуть однаковими незалежно від типу додатку, який ви створюєте. Кожен додаток має доступ до однакових функцій виконання, API та мови. Також включає покращення продуктивності CoreFX, які робляться майже щодня.
Все, що ви любите в .NET Core, буде існувати:
- Відкритий код і орієнтований на спільноту на GitHub.
- Кросплатформенна реалізація.
- Підтримка використання специфічних для платформи функцій, таких як Windows forms і WPF на Windows, а також нативних прив'язок для кожної нативної платформи від Xamarin.
- Висока продуктивність.
- Встановлюйте поруч.
- Невеликі файли проєктів (у стилі SDK).
- Сумісний з інтерфейсами командного рядка (CLI).
- Інтеграція Visual Studio, Visual Studio для Mac та Visual Studio Code.
Є також деякі нові речі:
- У вас буде більше варіантів для вашого досвіду виконання (про це нижче).
- Сумісність Java буде доступна на всіх платформах.
- Кілька операційних систем підтримуватимуть сумісність Objective-C та Swift.
- CoreFX буде розширено для підтримки передчасного використання (AOT) для .NET, меншого обсягу та підтримки більшої кількості операційних систем.
Ми випустимо .NET Core 3.0 у вересні цього року, .NET 5 — у листопаді 2020 року, а потім плануємо випустити основну версію . NET:
Ми пропустили версію 4, бо це могло б заплутати користувачів, знайомих із .NET Framework, який існує вже давно з серією 4.x. Крім того, ми хочемо чітко донести, що .NET 5 — це майбутнє платформи .NET. Назвати це .NET 5 — це найвища версія, яку ми коли-небудь випускали.
Ми також користуємося цією нагодою, щоб спростити назви. Ми вважаємо, що якщо найкращим є лише один .NET, нам не потрібен уточнюючий термін на кшталт «Core». Коротша назва є спрощенням і також передає повідомлення, що .NET 5 має однорідну функціональність і поведінку. Звісно, ви можете й надалі використовувати назву «.NET Core», якщо бажаєте.
Досвід виконання
Mono є оригінальною кросплатформенною реалізацією .NET. Він починався як відкрита альтернатива .NET Framework і перейшов на мобільні пристрої з популярністю пристроїв iPhone/iOS та Android. Моно — це режим виконання, який використовується як частина Xamarin.
CoreCLR — це середовище виконання, яке використовується як частина .NET Core. Він переважно використовується для підтримки хмарних додатків, включно з найбільшим сервісом Microsoft, а зараз також застосовується у Windows-настільних комп'ютерах, IoT та додатках машинного навчання.
Підсумовуючи, .NET Core і Mono мають багато спільного (адже обидва — .NE), але також мають цінні унікальні функції. Дуже логічно зробити можливим обирати бажаний досвід виконання виконання. Ми робимо CoreCLR і Mono взаємозамінними між собою. Ми зробимо це настільки простим, як створити комутатор, щоб обирати між різними варіантами виконання.
Наступні розділи описують основний фокус, який ми плануємо використовувати для .NET 5. Вони дають чітке уявлення про те, як ми плануємо розвивати ці два рантайми окремо та разом.
Висока пропускна здатність і висока продуктивність
Від самого початку .NET покладався на компілятори just-in-time (JIT) для перетворення коду проміжної мови (IL) в оптимізований машинний код. Відтоді ми створили провідний у галузі керований процесор на основі JIT, який має дуже високу пропускну здатність і покращує досвід розробників, роблячи програмування швидким і простим.
JIT ідеально підходить для довготривалих хмарних та клієнтських сценаріїв. Вони можуть генерувати код, налаштований для конкретних машин, включаючи конкретні інструкції процесора. JIT також може генерувати методи під час виконання — техніка, яка робить JIT швидшою, при цьому зберігаючи можливість генерувати високооптимізовані версії коду, якщо це стане часто використовуваним методом.
Наші зусилля зробити ASP.NET Core швидшим на бенчмарку Techpower є чудовим прикладом потужності JIT та наших інвестицій у CoreCLR. Наші зусилля щодо посилення .NET Core для контейнерів також свідчать про здатність середовища виконання динамічно адаптуватися до обмежених середовищ.
Інструменти для розробників — ще один чудовий приклад того, наскільки JIT справді чудовий, наприклад, dotnet watch tools або edit and continue. Інструментам часто потрібно компілювати та завантажувати код кілька разів у одному процесі без перезавантаження, і робити це дуже швидко.
Розробники, які використовують .NET Core або .NET Framework, переважно покладаються на JIT. Тому досвід має бути знайомим.
Для більшості робочих сценаріїв .NET 5 за замовчуванням використовується CoreCLR на основі JIT. Два помітні винятки — iOS та клієнтський Blazor (веб-асемблер), оскільки обидва вимагають нативної компіляції заздалегідь (AOT).
Швидкий запуск, малий об'єм і низьке використання пам'яті
Більшість проєкту Mono зосереджена на мобільних та консолях. Ключовою особливістю та результатом проєкту є компілятор .NET AOT, заснований на провідному в галузі проєкті компілятора LLVM. Компілятор Mono AOT дозволяє інтегрувати .NET-код у власний виконуваний код, який може працювати на комп'ютері, подібно до коду C++. Додатки, скомпільовані AOT, можуть ефективно працювати в менших локаціях і обмінюватися пропускною здатністю для запуску за потреби.
Проєкт Blazor вже використовує Mono AOT. Це буде один із перших проєктів, що перейдуть на .NET 5. Ми використовуємо це як один із варіантів для підтвердження цього плану.
Існує два типи рішень AOT:
- Потрібне рішення, яке на 100% скомпілюється AOT.
- Більшість коду — це рішення, скомпільоване AOT, але JIT або інтерпретатори можуть використовуватися для кодових шаблонів, які не є дружніми до AOT (наприклад, генерики). Mono AOT підтримує обидва випадки. Apple вимагає перший AOT для iOS і деяких консолей з міркувань безпеки. Другий метод — кращий варіант, оскільки він має переваги AOT і уникає деяких недоліків.
.NET Native — це наш компілятор AOT для додатків Windows UWP, а також приклад першого типу AOT, згаданого вище. У цій конкретній реалізації ми обмежуємо .NET API та можливості, які ви можете використовувати. Ми дізналися з цього досвіду, що рішення AOT повинні охоплювати всі аспекти .NET API та патернів.
Компіляція AOT все ще потрібна на iOS, веб-асемблері та деяких консолях. Для додатків, які потребують швидшого запуску або малої площі, ми зробимо компіляцію AOT опцією.
Народження проєкту
Ми розпочали цей проєкт у грудні 2018 року з технічною командою в Бостоні. Керівники дизайну з команди .NET (Mono/Xamarin і .NET Core) та Unity представили різноманітні технічні можливості та архітектурні напрямки.
Зараз ми рухаємо цей проєкт вперед як команда, маючи набір результатів. Ми досягли значного прогресу у низці проєктів з грудня:
- Визначено мінімальний шар, який визначає керований кодовий шар <-> під час виконання з метою досягнення >99% публічного коду CoreFX.
- MonoVM тепер може використовувати CoreFX та його бібліотеки класів.
- Запустіть усі тести CoreFX на MonoVM з реалізацією CoreFX.
- Запускайте ASP.NET Core 3.0 додатки з MonoVM.
- Запусти MonoDevelop на CoreCLR, потім Visual Studio для Mac.
Перейдіть на один . Реалізація .NET породжує важливі питання: Якою буде цільова структура? Чи однакові правила сумісності пакетів NuGet? Які навантаження має підтримувати .NET 5 SDK? Як мені кодувати для конкретної архітектури? Чи потрібен нам ще .NET Standard?
Ми зараз працюємо над цими питаннями і незабаром поділимося дизайн-документом, щоб ви могли прочитати та надати відгуки.
Епілог
Проєкт .NET 5 — це важливий і захоплюючий новий напрямок для .NET. Ви побачите, що .NET стає простішим, але також з ширшим спектром функцій і корисностей. Усі нові розробки та функції будуть частиною .NET 5, включно з новими версіями на C#.
Ми бачимо світле майбутнє, де ви зможете використовувати одні й ті ж .NET API та мови для широкого спектра типів додатків, операційних систем і кремнієвих архітектур. У Visual Studio, Visual Studio для Mac, Visual Studio Code, Azure DevOps або командному рядку легко змінити конфігурацію збірки для створення різних додатків.
Оригінальне посилання:Вхід за гіперпосиланням видно.
|
Опубліковано 07.05.2019 09:41:27
|
|
|
|
