Posted on 15. February 2024

Our Vision for .NET 9

Наше бачення .NET 9

Ласкаво просимо до .NET 9! Ми знаходимося на початку чергового річного циклу випусків після успішного запуску .NET 8 кілька місяців тому. Ми рекомендуємо розробникам перевести свої програми на .NET 8. У цій статті ми поділимося нашим початковим баченням .NET 9, який буде представлений на конференції .NET Conf 2024 наприкінці року. Наші найважливіші напрямки – це хмарна та інтелектуальна розробка додатків. Ви можете очікувати значних інвестицій в продуктивність, продуктивність і безпеку, а також вдосконалення всієї платформи.


Сьогодні ми розглянемо основні напрямки .NET 9 та додаткові інтеграції, які ми плануємо реалізувати у співпраці з партнерськими командами Microsoft. Наша мета – зробити розробку .NET більш продуктивною за допомогою Visual Studio, Visual Studio Code з C# Dev Kit, а хмарне розгортання – простішим за допомогою служб Azure. Ми продовжимо тісно співпрацювати з нашими галузевими партнерами, такими як Canonical та Red Hat, щоб гарантувати, що .NET чудово працює, де б ви його не використовували.


.NET 9 стає ще одним важливим кроком вперед для платформи. Сьогодні ми випускаємо попередню версію .NET 9 Preview 1 і будемо раді вашим відгукам про всі нові функції, які ми надали.


Платформа для хмарних розробників

Останні кілька років ми витратили на створення міцних основ хмарних технологій, таких як продуктивність під час виконання та моніторинг додатків. Ми продовжимо цю роботу. Ми також зосереджуємо нашу увагу на наданні прокладених шляхів до популярної виробничої інфраструктури та сервісів, наприклад, на роботі в Kubernetes та використанні керованих баз даних і сервісів кешування, таких як Redis. Ми будемо впроваджувати ці покращення на різних рівнях стеку .NET. Всі ці можливості об’єднані в .NET Aspire, який значно зменшує вартість і складність створення хмарних додатків, а також відстань між розробкою та виробництвом.


Ми розробляємо нативний AOT і тримінг додатків як ключові інструменти для оптимізації виробничих додатків. У .NET 8 ми оптимізували додатки Web API (використовуючи шаблон webapiaot) як для тримінгу, так і для AOT. У .NET 9 ми працюємо над тим, щоб зробити те ж саме з іншими типами додатків і вдосконалити DATAS GC для всіх додатків ASP.NET Core.


Наші партнери з Azure Container Apps гарантують, що програми .NET 9 можна легко масштабувати до кількох екземплярів у їхньому середовищі на базі Kubernetes. Ми працюємо з ними над тим, щоб забезпечити правильне шифрування ефемерних даних, таких як токени для захисту від підробки та авторизації, за допомогою засобів захисту даних, а також над удосконаленням API з обмеженням швидкості, щоб забезпечити оптимальну поведінку для кожного вузла та між вузлами.


Зразок програми-еталона архітектури eShop, який був представлений на конференції .NET Conf минулого року, буде оновлено, щоб скористатися цими новими можливостями та варіантами розгортання в міру розвитку .NET 9 протягом року.


Інструменти для хмарних розробників

Наші партнери по Visual Studio планують вдосконалення, які підтримують та розширюють нашу хмарну платформу, Native AOT, .NET Aspire та розгортання Azure.


Компіляція коду Native AOT вимагає встановлення та використання інструментів, які багато .NET розробників зазвичай не використовують. Розробники, які хочуть здійснювати крос-компіляцію (наприклад, націлити Linux на Windows), наразі покладаються на Docker та/або WSL2, керуючись нашою документацією та прикладами. Підтримка AOT у Visual Studio буде розширюватися, щоб зробити нативний AOT доступним для більшої кількості розробників.


Visual Studio та Visual Studio Code включатимуть нові можливості розробки та розгортання для .NET Aspire. Це включає в себе налаштування компонентів, налагодження (включаючи гаряче перезавантаження) AppHost і дочірніх процесів, а також повну інтеграцію з інформаційною панеллю розробника. Розробники зможуть розгортати свої проекти в Azure Container Apps з Visual Studio, Visual Studio Code і за допомогою Azure Developer CLI (azd).


.NET та штучний інтелект

OpenAI викликав ажіотаж серед розробників, пропонуючи можливість трансформувати свої додатки за допомогою штучного інтелекту. Протягом минулого року Azure Open AI та .NET використовувалися для створення рішень зі штучним інтелектом, найпопулярнішим з яких став Microsoft Copilot. Ми продовжуватимемо співпрацювати з клієнтами, які шукають способи використання своїх навичок C# для створення цього нового класу додатків, а також швидко інвестувати в нашу платформу ШІ.


У .NET 8 ми розширили наші інвестиції за межі ML.NET. Ми зосередилися на робочих навантаженнях ШІ, інвестували в початкові зразки та документацію, а також співпрацювали з партнерами з екосистеми ШІ, щоб створити клієнти C# для векторних баз даних, таких як Qdrant і Milvus, і бібліотек, таких як Semantic Kernel. Крім того, ми додали TensorPrimitives для .NET.


Заглядаючи вперед, до .NET 9, ми прагнемо зробити так, щоб розробникам .NET було ще простіше інтегрувати штучний інтелект у свої існуючі та нові додатки. Розробники знайдуть чудові бібліотеки та документацію для роботи з моделями OpenAI та OSS (хостинговими та локальними), а ми продовжимо співпрацювати над Semantic Kernel, OpenAI та Azure SDK, щоб гарантувати, що .NET розробники матимуть першокласний досвід створення інтелектуальних додатків.


Ми будемо оновлювати ChatGPT + Enterprise Data з Azure OpenAI та Cognitive Search .NET Sample на GitHub протягом усього випуску.


.NET 9 Беклог

Ці хмарні проекти та проекти зі штучного інтелекту – лише частина того, що ми пропонуємо. Ми опублікували бэклоги для .NET MAUI, ASP.NET Core та Blazor, C#, F# та інших компонентів середовища виконання та інструментів, що входять до складу .NET SDK. Ознайомтеся з бэклогом проекту .NET 9 на GitHub, щоб дізнатися про ваші улюблені області та функції.


Ми регулярно визначаємо нові функції та оновлюємо інформацію про прогрес. Ми будемо оновлювати наш бэклог і примітки до випусків .NET 9 по мірі просування. Ми також працюємо над деякими експериментами, які можуть стати частиною майбутнього випуску.


Спробуйте .NET 9 Preview 1

.NET 9 Preview 1 тепер доступна для завантаження. Надалі ми будемо публікувати попередні версії на GitHub Discussions. Ми адаптуємо вміст нашого блогу .NET, щоб підкреслити переваги .NET 8, прагнучи підтримати ваше використання .NET 8 у виробничих середовищах.


Сьогодні ми також випускаємо .NET Aspire Preview 3. Цей випуск включає в себе покращення інтерфейсу користувача на інформаційній панелі та підтримку нових компонентів, включаючи Azure OpenAI, Kafka. Oracle, MySQL, CosmosDB та Orleans.

 

Якщо попередні версії не для вас, ознайомтеся з публікацією про випуск .NET 8. Ми чули багато хороших відгуків про раннє розгортання .NET 8. Перехід на .NET 9 з .NET 8 (і попередніх версій) має бути дуже простим.



Posted on 15. July 2023

Анонс .NET 8 Preview 6

 

 

Ми раді повідомити вам про найновіші функції та вдосконалення, доступні в .NET 8 Preview 6 ! Цей випуск є продовженням випуску Preview 5 , і ми прагнемо надавати вам все більше вдосконалень з кожним місячним випуском.

 

Сьогодні ми маємо справу із захоплюючим релізом з великою кількістю оновлень бібліотеки, новим режимом WASM, більшою кількістю генераторів джерел, постійними покращеннями продуктивності та підтримкою NativeAOT на iOS. Сподіваємося, вам сподобаються ці нові функції та вдосконалення. Слідкуйте за новинами, оскільки ми продовжуємо наш шлях до покращення .NET разом!


Ви можете завантажити .NET 8 Preview 6 для Linux, macOS і Windows.


Будьте в курсі новинок у .NET 8 . Він оновлюватиметься протягом випуску.


А тепер поглянемо на нові функції .NET 8.

 

Покращення System.Text.Json

Ми внесли низку вдосконалень у генератор вихідних кодів System.Text.Json, головним чином спрямованих на те, щоб Native AOT порівнявся з серіалізатором на основі відображення.

- Додано підтримку кешування для інкрементного генератора, що покращує продуктивність IDE у великих проєктах. https://github.com/dotnet/runtime/pull/86121 

- Покращене форматування згенерованого вихідного коду, включно з виправленням ряду проблем із відступами https://github.com/dotnet/runtime/pull/86526 , https://github.com/dotnet/runtime/pull/87557 

- Додано ряд нових діагностичних попереджень https://github.com/dotnet/runtime/pull/87980

- Виправлено ряд помилок, пов’язаних із роздільною здатністю модифікатора доступності https://github.com/dotnet/runtime/pull/87136 

- Гарантія, що типи ігнорованих або недоступних властивостей не включені генератором https://github.com/dotnet/runtime/pull/87383 

- Виправлено проблеми, пов’язані з підтримкою JsonNumberHandling https://github.com/dotnet/runtime/pull/87484 

- Виправлено підтримку рекурсивних типів колекцій https://github.com/dotnet/runtime/pull/87632 

- Виправлено підтримку спеціального конвертера для структур, що допускають значення NULL https://github.com/dotnet/runtime/pull/84208 

- Виправлено ряд помилок у реалізації синтаксичного аналізу атрибутів під час компіляції https://github.com/dotnet/runtime/pull/87796 

 

- Додано підтримку вкладеності декларацій JsonSerializerContext в довільних типах https://github.com/dotnet/runtime/pull/87829

 

JsonStringEnumConverter

Цей новий конвертер доповнює наявний клас JsonStringEnumConverter, який не підтримується в Native AOT.

Користувачі, які бажають націлитися на користувачів Native AOT, повинні анотувати свої типи переліків наступним шаблоном.

 

 

JsonConverter.Type

 

 

Нова властивість дозволяє користувачам шукати тип незагального образу JsonConverter:

 

Властивість має значення NULL, оскільки повертає null для екземплярів JsonConverterFactory і для typeof(T)екземплярів JsonConverter.

 

Перевантаження методів ZipFile CreateFromDirectory та ExtractToDirectory на основі потоку

Ми додали нові перевантаження ZipFile.CreateFromDirectory, які дозволяють користувачам збирати всі файли, включені в каталог, і архівувати їх, а потім зберігати отриманий файл zip у наданому потоці.

Симетрично ми додали перевантаження ZipFile.ExtractToDirectory, які дозволяють користувачам надавати потік, що містить архівований файл, і витягувати його вміст у файлову систему.

Ці API дозволяють уникнути необхідності використовувати диск як проміжний крок. Це може бути корисним у ситуаціях, коли дисковий простір обмежений, як, наприклад, у хмарних середовищах:

- CreateFromDirectory дозволяє не записувати заархівований результат на диск.

 

- ExtractToDirectory не вимагає, щоб заархівований файл знаходився на диску.

 Використання ZipFile.CreateFromDirectory

 

Використання ZipFile.ExtractToDirectory


Метрики API MetricCollector

MetricCollector — це новий клас, призначений для тестування сценаріїв. Раніше він називався InstrumentRecorder. Ми значно вдосконалили цей клас і перемістили його в пакет Microsoft.Extensions.Telemetry.Testing .

Тепер клас MetricCollector може записувати метричні вимірювання разом із часовими мітками. Крім того, клас пропонує гнучкість використання будь-якого бажаного постачальника часу для точного створення позначок часу.

 

Наступний приклад демонструє, як використовувати цю функцію.

Використання MetricCollector

Представляємо генератор джерела перевірки параметрів

Щоб зменшити витрати на запуск і покращити набір функцій перевірки, ми представили генератор вихідного коду , який реалізує логіку перевірки.


Використання перевірки параметрів


Якщо програма використовує ін’єкцію залежностей, вона може ін’єктувати перевірку за таким шаблоном.

 

Розширення перевантажень конструктора LoggerMessageAttribute для підвищення функціональності


Були введені нові LoggerMessageAttribute перевантаження конструктора, які пропонують більшу гнучкість у визначенні необхідних параметрів за допомогою скорочення коду. Нові перевантаження конструктора включають такі параметри, як визначення лише LogLevel і повідомлення, лише LogLevel або лише повідомлення.


Ці вдосконалення полегшують користувачам визначення атрибутів LoggerMessageAttributes, мінімізуючи непотрібний код.

 

Використання LoggerMessage

 

Наступний приклад демонструє реалізацію LoggerMessage, яка раніше була неможлива.

 

Примітка : у пізнішому прев’ю, для конструкторів, яким не потрібен ідентифікатор події, система автоматично згенерує ідентифікатор події, усуваючи потребу вручну надавати його користувачам.

 

Покращення генератора джерела прив’язки конфігурації

У Прев’ю № 3 ми представили новий джерельний генератор для забезпечення AOT і зручної конфігурації в ASP.NET Core . Генератор є альтернативою існуючій реалізації на основі відображення. Відтоді ми внесли кілька покращень на основі відгуків спільноти, і генератор готовий, щоб люди могли спробувати його ще раз за допомогою Preview 6.


Приклад програми , яка використовує зв’язування конфігурації та публікується з AOT, змінюється від двох (2) попереджень аналізу AOT під час компіляції до жодного. ДДодаток не працював при виконанні, але тепер він працює.


Для використання генератора не потрібно змінювати вихідний код. Його ввімкнено за замовчуванням у веб-програмах Native AOT. Для інших типів проектів його вимкнено за замовчуванням, але ви можете керувати ним, додавши наступну властивість до свого проекту.

Ви можете знайти відомі проблеми тут .

 

Генерований джерелом COM Interop


Тепер у нас є новий джерельний генератор, який підтримує взаємодію з COM-інтерфейсами за допомогою підтримки взаємодії, створеної джерелом , з якої ми почали LibraryImportAttribute. Ви можете використовувати System.Runtime.InteropServices.Marshalling.GeneratedComInterfaceAttribute, щоб позначити інтерфейс як інтерфейс COM для вихідного генератора. Потім генератор вихідного коду згенерує код, щоб увімкнути виклик із коду C# до некерованого коду, а також код, щоб увімкнути виклик із некерованого коду в C#. Цей джерельний генератор інтегрується з LibraryImportAttribute, і ви можете використовувати типи з параметрами GeneratedComInterfaceAttribute  і повертати типи в методах LibraryImportAttributе.

 

 

Генератор вихідних кодів COM забезпечує зрозумілий досвід роботи з IDE через аналізатори та виправлення коду. Це схоже на LibraryImportAttribute. Біля кожного інтерфейсу, який має System.Runtime.InteropServices.ComImportAttribute, лампочка пропонуватиме опцію перетворення на взаємодію, згенеровану джерелом. Це виправлення змінить інтерфейс для використання GeneratedComInterfaceAttribute. Біля кожного класу, який реалізує інтерфейс із GeneratedComInterfaceAttribute, лампочка запропонує опцію додати GeneratedComClassAttribute до типу. Після перетворення типів ви можете використовувати  свої методи DllImport, щоб використати LibraryImportAttribute з наявним там засобом виправлення коду. За допомогою цих двох лампочок можна легко перетворити наявний код взаємодії COM для використання нового взаємодії, створеного джерелом. Також є більше аналізаторів, які допомагають виявити місця, де ви можете змішувати COM-взаємодію, згенеровану джерелом, і на основі середовища виконання, що може потребувати додаткової роботи.

 

 

У рамках цього проекту ми оновили бібліотеку System.Transactions для використання нової взаємодії, створеної джерелом! Ми використали цей досвід, щоб допомогти вдосконалити аналізатори та засоби виправлення коду, щоб забезпечити якісний досвід міграції.

 

Використання GeneratedComInterface

 

GeneratedComClassAttribute

 

Генератор вихідного коду також підтримує новий System.Runtime.InteropServices.Marshalling.GeneratedComClassAttribute , щоб дозволити вам передавати ваші типи, які реалізують інтерфейси з System.Runtime.InteropServices.Marshalling.GeneratedComInterfaceAttribute – атрибутованих інтерфейсів до некерованого коду. Генератор вихідного коду згенерує код, необхідний для надання COM-об’єкта, який реалізує інтерфейси та перенаправляє виклики до керованої реалізації.

 

Використання GeneratedComClassAttribute

 

Взаємодія з LibraryImportAttribute


Методи в інтерфейсах з підтримкою GeneratedComInterfaceAttribute всіх тих самих типів, що й LibraryImportAttribute, і LibraryImportAttribute отримують підтримку для атрибутованих типів GeneratedComInterface та  атрибутованих типів GeneratedComClass в цьому випуску.

Якщо у вашому коді C# використовуватиметься лише GeneratedComInterfaceAttributeатрибутований інтерфейс або для обгортання COM-об’єкта з некерованого коду, або для обгортання керованого об’єкта з C# для некерованого коду, ви можете використовувати параметри у властивості GeneratedComInterfaceAttribute.Options, щоб налаштувати, який код буде згенеровано. Цей параметр дозволить вам не писати маршаллери для сценаріїв, які, як ви знаєте, не використовуватимуться.

 

Генератор джерела використовує новий тип System.Runtime.InteropServices.Marshalling.StrategyBasedComWrappers для створення та керування оболонками об’єктів COM і оболонками керованих об’єктів. Цей новий тип забезпечує очікувану взаємодію .NET з COM-взаємодією, а також надає точки налаштування для досвідчених користувачів. Якщо ваша програма має власний механізм для визначення типів із COM або якщо вам потрібно підтримувати сценарії, які наразі не підтримує COM, створений джерелом, ви можете розглянути можливість використання нового типу StrategyBasedComWrappers, щоб додати відсутні функції для вашого сценарію та отримати той самий .NET досвід користувача для ваших типів COM.

Обмеження

На цю мить вихідний генератор COM має такі обмеження. Ми не плануємо усувати ці обмеження в .NET 8, але можливо в майбутній версії .NET.

Немає підтримки інтерфейсів на основі IDispatch.

Підтримка цих інтерфейсів може бути реалізована вручну за допомогою локального визначення інтерфейсу IDispatch.

– Немає підтримки інтерфейсів на основі IInspectable.

Використовуйте інструмент CsWinRT , щоб створити код взаємодії для цих інтерфейсів.

– Немає підтримки спорідненості апартаментів.

Передбачається, що всі COM-об’єкти є безпотоковими. Підтримку спорідненості апартаментів можна впровадити вручну за допомогою реалізацій типу StrategyBasedComWrappers та спеціальної стратегії.

– Немає підтримки властивостей COM.

Вони можуть бути реалізовані вручну як методи в інтерфейсі.

– Немає підтримки подій COM.

Вони можуть бути реалізовані вручну за допомогою базових API COM.

– Не підтримується використання ключового слова new для активації COM CoClass.

 

Використовуйте LibraryImportAttribute для P/Invoke до CoCreateInstance API, щоб активувати CoClass.

Підтримка HTTPS проксі

https://github.com/dotnet/runtime/issues/31113

Хоча HttpClient деякий час підтримував різні типи проксі, усі вони дозволяють людині посередині бачити, до якого сайту підключається клієнт. (навіть для HTTPS URI) Проксі-сервер HTTPS дозволяє створити зашифрований канал між клієнтом і проксі-сервером, щоб усі наступні запити могли оброблятися з повною конфіденційністю.

Використання проксі HTTPS

– Unix: export all_proxy=https://x.x.x.x:3218

– Windows: set all_proxy=https://x.x.x.x:3218

 

Цим також можна керувати програмно через WebProxy .

 

System.Security: підтримка SHA-3

Підтримка примітивів хешування SHA-3 тепер доступна на платформах, які пропонують SHA-3. Зараз це Linux із OpenSSL 1.1.1+ і Windows 11 build 25324+.

API, де доступний SHA-2, тепер пропонують доповнення SHA-3. Воно містить SHA3_256, SHA3_384 і SHA3_512 для хешування; HMACSHA3_256, HMACSHA3_384, і HMACSHA3_512 для HMAC; HashAlgorithmName.SHA3_256, HashAlgorithmName.SHA3_384, та HashAlgorithmName.SHA3_512 для хешування, де алгоритм можна налаштувати; і RSAEncryptionPadding.OaepSHA3_256, RSAEncryptionPadding.OaepSHA3_384, та RSAEncryptionPadding.OaepSHA3_512 для шифрування RSA OAEP.

Використання API SHA-3 подібне до SHA-2, з додаванням властивості IsSupported, щоб визначити, чи пропонує платформа SHA-3.

Крім того, SHA-3 включає дві функції розширюваного виведення (XOF), SHAKE128 і SHAKE256. Вони доступні як Shake128і Shake256.

 

Підтримка SHA-3 наразі спрямована на підтримку криптографічних примітивів. Очікується, що конструкції та протоколи вищого рівня спочатку не повністю підтримуватимуть SHA-3. Це включає, але не обмежується сертифікатами X.509 SignedXmlі COSE. Підтримка SHA-3 може розширитися в майбутньому залежно від підтримки платформи та стандартів, які використовують SHA-3.

 

SHA-3 був стандартизований NIST як FIPS 202 як альтернатива, а не наступник SHA-2. Розробники та організації повинні вирішити, коли й навіть чи підходить їм прийняття SHA-3.

SDK: продуктивність і сумісність публікації контейнерів

Ми внесли кілька змін до стандартних значень створених зображень для програм .NET 8.


– Зображення тепер за замовчуванням використовують нову безкореневу можливість контейнерів .NET , що робить ваші програми безпечними за замовчуванням. Ви можете будь-коли змінити це, встановивши власний ContainerUser, як root.

– Зображення позначені тегами latest за замовчуванням, як і інші інструменти для контейнерів.


Ми покращили продуктивність надсилання контейнерів до віддалених реєстрів, надійність операції надсилання та підтримку більшого діапазону реєстрів. У той же час Том Десейн з Red Hat був зайнятий вдосконаленням нашої підтримки для ряду поширених реалізацій контейнерів.


У цій версії має бути значно покращена продуктивність для надсилання контейнерів, особливо до реєстрів Azure. Це саме завдяки нашій покращеній підтримці просування шарів за одну операцію. Крім того, для реєстрів, які не підтримують атомарне завантаження, ми запровадили більш надійний механізм завантаження фрагментів, який можна повторити.


Як побічний ефект цих змін ми також розширили нашу матрицю підтримки для реєстрів. Harbor і Artifactory приєдналися до списку відомих працюючих реєстрів, а робота Тома також уможливила запуск Quay.io і Podman.

 

Режим HybridGlobalization на WASM

 

Програми WASM можуть використовувати новий режим глобалізації, який полегшує пакет ICU та натомість використовує веб-API. У гібридному режимі дані глобалізації частково витягуються з пакета ICU, а частково – із викликів у JS. Він обслуговує всі регіони, які підтримує WASM .

 

Коли розглядати можливість використання HybridGlobalization

 

Цей параметр найбільше підходить для програм, які не можуть працювати в режимі InvariantGlobalization та використовувати дані локалізації з кількох сегментів ICU (EFIGS, CJK, no-CJK), тому наразі використовується:

у Blazor WebAssembly або

у браузері WASM.

Програми, які завантажували no-CJK або CJK shard за допомогою спеціального методу завантаження файлу ICU :
також може бути цікаво, тому що гібридний файл менший за фрагмент без CJK на 26% і менший за CJK на 15%.

Як використовувати HybridGlobalization

Установіть властивість MsBuild: true. Він завантажить файл icudt_hybrid.dat, який на 46% менший, ніж початково завантажений icudt.dat.

Обмеження

Через обмеження веб-API не всі API глобалізації підтримуються в гібридному режимі. Деякі з підтримуваних API змінили свою поведінку. Щоб переконатися, що це не вплине на вашу програму, прочитайте розділ Поведінкові відмінності для WASM .


API, які отримують результат шляхом звернення до JS, мають гіршу продуктивність, ніж негібридна версія. Ці API перераховані в документації . Інтерфейси API, яких немає в списках «Уражені публічні API», працюють так само, як і в негібридному режимі.

 

Підтримка націлювання на платформи iOS за допомогою NativeAOT

Тепер ми маємо підтримку націлювання на iOS-подібні платформи за допомогою Native AOT. Сюди входить створення й запуск програм .NET iOS, .NET MAUI а також NativeAOT з такими системами: ios, iossimulator, maccatalyst, tvos або tvossimulator. Мотивація цієї роботи полягає в тому, щоб дозволити користувачам вивчити можливість досягнення кращої продуктивності та економії розміру при орієнтації на такі платформи за допомогою. 

 

Ця функція доступна як додаткова функція, призначена для розгортання програми, коли Mono все ще використовується як вибір середовища виконання за умовчанням для розробки та розгортання програми. Ця віха була досягнута завдяки чудовій співпраці між членами нашої спільноти: @filipnavara @AustinWise та @am11 , які зробили внесок своєю роботою та спільними зусиллями NativeAOT, Mono і Xamarin команд.

Поточний стан

Поточний стан перевірено за допомогою:

.NET iOS app( )dotnet new ios

.NET MAUI iOS app( )dotnet new maui

 

Ці зразки програм показують такі попередні результати порівняно з Mono:

Результати .NET 8 Preview 6  (позначені як *-p6) показують, що .NET iOS app має значні покращення порівняно з Mono, де пакет стисненого додатка (.ipa) досяг на ~39% меншого розміру, демонструючи великий потенціал, тоді як .NET MAUI iOS app показує гірші результати, створюючи на ~13% гірший результат. Однак ми визначили основну причину регресії розміру за допомогою програми .NET MAUI, і наразі ми працюємо над таким списком проблем, щоб усунути регресію розміру:

1. https://github.com/xamarin/xamarin-macios/pull/18532

2. https://github.com/xamarin/xamarin-macios/issues/18479 

3. https://github.com/dotnet/runtime/issues/87924 

4. https://github.com/dotnet/runtime/issues/86649 

Ми оцінили, що усунувши виявлені проблеми 1-3), NativeAOT може досягти чудових результатів із додатком .NET MAUI, який показано в стовпці NativeAOT-fix, де розмір пакета додатків менший на  ~30%  порівняно з Mono. Виправлення проблеми 4) може ще більше покращити продуктивність, але на даному етапі ми не можемо оцінити точні цифри. Більше інформації про продуктивність .NET MAUI з NativeAOT відстежується на: https://github.com/dotnet/runtime/issues/80907

Відзначимо, що висновки щодо продуктивності NativeAOT на iOS-подібних платформах не слід робити ні з наведених у таблиці чисел, ні з випуску .NET 8 Preview 6 в цілому. Тим паче, що це все ще триває і це лише перший крок до того, щоб зробити функцію готовою до офіційного випуску .NET 9. Тому ми активно працюємо над удосконаленнями та визначаємо всю роботу, яка намагатиметься надати нашим клієнтам повний досвід NativeAOT для досягнення високої продуктивності та економії розміру, що відстежується в наведеному нижче списку проблем (та їхніх підзавдань):

– https://github.com/dotnet/runtime/issues/80905 tracks: Загальний прогрес

– https://github.com/xamarin/xamarin-macios/issues/17339 tracks: покращення інтеграції Xamarin

 

– https://github.com/dotnet/runtime/issues/86649 tracks: Покращення сумісності з обрізанням і розширеннями=

 

Як створити та запустити програму .NET MAUI за допомогою NativeAOT на пристрої iOS із .NET CLI

Встановлення

Створення образу програми

Вибір NativeAOT замість Mono

Властивості MSBuild PublishAot=true і PublishAotUsingRuntimePack=true (тимчасові, див. нижче) дозволяють розгортання NativeAOT.

Ці дві властивості є єдиною помітною відмінністю в порівнянні з розгортанням за допомогою Mono. Вам потрібно додати їх у PropertyGroup файлу проєкту вашої програми:

Це означає, що щоразу, коли програму розгортають через dotnet publish, вона розгортатиметься за допомогою NativeAOT.

Запуск програми

Сумісність з iOS і NativeAOT

Не всі функції iOS сумісні з NativeAOT. Так само не всі бібліотеки, які зазвичай використовуються в iOS, сумісні з NativeAOT. .NET 8 означає початок роботи над увімкненням NativeAOT для iOS. Ваші відгуки допоможуть нам спрямовувати наші зусилля під час попереднього перегляду .NET 8 і далі, щоб ми зосередилися на тих місцях, де переваги NativeAOT можуть мати найбільший вплив.

У наведеному нижче списку є деякі обмеження під час націлювання на iOS-подібні платформи, які зустрічалися досі (тому це може бути не остаточний список):

– Встановлення та розгортання програми за допомогою Visual Studio ще не перевірено

Використання NativeAOT ввімкнено лише під час розгортання програми dotnet publish

Функціональні можливості бібліотеки Linq.Expressions ще не повністю підтримуються

Властивість MSBuild PublishAotUsingRuntimePack=true — це тимчасовий обхідний шлях, необхідний для націлювання на iOS-подібні платформи за допомогою NativeAOT 

Ця вимога стане неактуальною після виправлення: https://github.com/dotnet/runtime/issues/87060

Налагодження керованого коду підтримується лише з Mono

 

ПРИМІТКА. Попередній список є розширенням обмежень, які застосовуються до всіх платформ NativeAOT: https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/docs/limitations.md

Резюме

.NET 8 Preview 6 містить захоплюючі нові функції та вдосконалення, які були б неможливі без наполегливої ​​роботи та відданості різноманітної команди інженерів Microsoft і пристрасної спільноти відкритих програм. Ми хочемо висловити нашу щиру подяку всім, хто зробив внесок у .NET 8 до цього часу , чи то через внески коду, звіти про помилки чи надання відгуків.

 

Ваш внесок відіграв важливу роль у створенні попереднього перегляду .NET 8, і ми з нетерпінням чекаємо на продовження спільної роботи, щоб побудувати світле майбутнє для .NET і всієї технологічної спільноти.

 

Source