Анонс ASP.NET Core в .NET 8

ASP.NET Core у .NET 8 — це комплексне рішення для сучасної веброзробки. Він задовольняє всі ваші потреби в веброзробці від фронтенду до бекенду. За допомогою Blazor, а також високопродуктивних внутрішніх API, і сервісів, які є надійними і безпечними, ви можете створювати красиві, насичені та інтерактивні вебдодатки.  ASP.NET Core у .NET 8 ідеально підходить для створення хмарних додатків, а чудові інструменти у Visual Studio та Visual Studio Code підвищують вашу продуктивність. Завдяки ASP.NET Core у .NET 8 кожен розробник є розробником повного стека!

.NET 8 тепер доступний – оновіть свої проєкти ASP.NET Core сьогодні!

Починаймо

Щоб розпочати роботу з ASP.NET Core у .NET 8, інсталюйте .NET 8 SDK . .NET 8 також входить до складу Visual Studio 2022 і підтримується у Visual Studio Code з C# Dev Kit.

Якщо ви новачок у ASP.NET Core, ви можете розпочати навчання, перейшовши на https://asp.net і ознайомившись із можливостями ASP.NET Core.

Що нового?

Давайте розглянемо деякі чудові нові функції та вдосконалення, доступні в ASP.NET Core у .NET 8.

Продуктивність

ASP.NET Core у .NET 8 — це найшвидший реліз! Порівняно з .NET 7, ASP.NET Core у .NET 8 на 18% швидший за тестом Techempower JSON і на 24% швидший за тестом Fortunes:

Ви можете прочитати все про покращення продуктивності ASP.NET Core у публікації блогу Бреннана Конроя « Покращення продуктивності в ASP.NET Core 8» .

Підтримка ASP.NET Core для нативного AOT

У .NET 8 ми представляємо власну підтримку AOT для ASP.NET Core, спочатку зосереджуючись на хмарних додатках API. Тепер можна опублікувати програму ASP.NET Core із власним AOT , створюючи автономну програму, яка завчасно (AOT) скомпільована до власного коду.

 

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

Переваги використання нативного AOT з ASP.NET Core

Публікація та розгортання нативної програми AOT може надати такі переваги:

–  Зменшений розмір диска: під час публікації з використанням власного AOT створюється єдиний виконуваний файл, який містить програму разом із підмножиною коду із зовнішніх залежностей, які використовує програма. 

Зменшення розміру виконуваного файлу може призвести до:

- Менші образи контейнерів, наприклад, у сценаріях розгортання в контейнерах.

- Зменшення часу розгортання через менші образи.

– Скорочений час запуску: нативні програми AOT можуть запускатися швидше, частково завдяки видаленню компіляції JIT. Скорочений запуск означає:

- Додаток готовий швидше обслуговувати запити.

- Покращене розгортання за допомогою оркестраторів контейнерів, які керують переходами від однієї версії програми до іншої.

– Зменшена потреба в пам’яті: програми ASP.NET Core, опубліковані як нативні AOT, можуть мати зменшені вимоги до пам’яті залежно від виконуваної роботи, оскільки вони ввімкнули новий режим DATAS GC за замовчуванням. Зменшення споживання пам’яті може призвести до більшої щільності розгортання та покращеної масштабованості.

Як приклад, ми запустили просту програму ASP.NET Core API у нашій лабораторії порівняльного аналізу, щоб порівняти відмінності в розмірі програми, використанні пам’яті, часу запуску та навантаженні ЦП, опублікованому з власним AOT і без нього:

Наведена вище таблиця показує, що публікація програми як нативної AOT значно покращує час запуску, розмір програми та використання пам’яті. Час запуску скорочено на 70%, розмір програми – на 89%, а використання пам’яті під навантаженням – на 57%!

Більш складний зразок програми API із методами CRUD-стилю, включаючи перевірку моделі, OpenAPI, автентифікацію JWT і авторизацію на основі політики, прив’язку конфігурації та присутність у базі даних PostgreSQL за допомогою Npgsql , вказує такі зміни в своїх показниках порівняно з нативним AOT:

Для цієї складнішої програми час запуску скорочено на 76%, розмір програми зменшено на 78%, а використання пам’яті під навантаженням – на 37% !

Ви можете досліджувати ці та інші показники на нашій загальнодоступній інформаційній панелі тестів.

Сумісність ASP.NET Core та нативної AOT

Не всі функції в ASP.NET Core сумісні з нативним AOT. Подібним чином не всі бібліотеки, які зазвичай використовуються в ASP.NET Core, сумісні з нативним AOT. .NET 8 є початком роботи над реалізацією нативного AOT в ASP.NET Core, з початковим фокусом на підтримку додатків, що використовують мінімальні API або gRPC і розгортаються в хмарних середовищах. Нагадуємо, що в .NET 7 з’явилася підтримка нативної публікації AOT для консольних проєктів. Ваші відгуки допоможуть скерувати наші зусилля для майбутніх випусків, щоб переконатися, що ми зосереджуємось на тих місцях, де переваги нативної AOT можуть мати найбільший вплив.

Нативні додатки AOT постачаються з кількома основними вимогами сумісності. До ключових належать:

– Без динамічного завантаження (наприклад, Assembly.LoadFile)

– Немає генерації коду виконання через JIT (наприклад, System.Reflection.Emit)

– Немає C++/CLI

– Немає вбудованого COM (стосується лише Windows)

– Потрібна обрізка, яка має обмеження

– Передбачає компіляцію в один файл, який має відомі несумісності

– Програми включають необхідні бібліотеки часу виконання (як самодостатні програми, збільшуючи їх розмір порівняно з програмами, що залежать від фреймворку)

Використання цих функцій, швидше за все, зробить програму несумісною з нативним AOT. Щоб допомогти перевірити, чи програма сумісна з AOT, інструменти видаватимуть попередження , коли виявлять використання несумісних функцій. Якщо використання міститься у вихідному коді самої програми, ці попередження відображатимуться як діагностика в редакторі та під час компіляції. Якщо використання відбувається в залежності (наприклад, пакет NuGet), попередження з’являться під час публікації, коли IL цілої програми буде скомпільовано до рідного коду.

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

У деяких випадках функціональні можливості в програмах або бібліотеках потрібно буде повторно реалізувати, щоб вони були сумісні з нативним AOT. Типовим прикладом цього є використання рефлексії для генерації коду під час виконання. Генератори вихідного коду Roslyn дозволяють генерувати код під час компіляції з такими ж можливостями виявлення та перевірки типу, як і відображення на основі часу виконання, і є корисною альтернативою під час підготовки до сумісності з нативним AOT.

У наведеній нижче таблиці підсумовано сумісність функцій ASP.NET Core із нативним AOT:

 

Ви можете переглянути поточні відомі проблеми щодо сумісності ASP.NET Core та рідної AOT у .NET 8 тут.

Під час створення програми зверніть увагу на попередження AOT . Коректна робота програми, яка видає попередження AOT під час публікації, не гарантується. Якщо ви не отримуєте жодних попереджень AOT під час публікації, ви повинні бути впевнені, що ваша програма працюватиме стабільно після публікації для AOT, як це було під час робочого процесу розробки F5 / dotnet run. Однак, все одно важливо ретельно перевірити свою програму під час переходу на власну модель розгортання AOT, щоб переконатися, що функціональні можливості, спостережувані під час розробки (коли програму не обрізано та скомпільовано за допомогою JIT), збережені у власному виконуваному файлі.

Мінімальні API та нативний AOT

Щоб зробити мінімальні API сумісними з нативним AOT, ми запровадили Генератор делегатів запитів (RDG) . RDG — це генератор вихідних кодів , який виконує роботу, подібну до RequestDelegateFactory(RDF) , перетворюючи різноманітні виклики MapGet(), MapPost()тощо у вашій програмі на RequestDelegate, пов’язані з указаними маршрутами, але замість того, щоб робити це в пам’яті вашої програми під час її запуску, він робить це під час компіляції та генерує код C# безпосередньо у вашому проєкті. Це видаляє генерацію цього коду під час виконання та гарантує, що типи, які використовуються у ваших API, зберігаються в коді вашої програми таким чином, що його можна статично проаналізувати власним ланцюжком інструментів AOT, гарантуючи, що необхідний код не буде обрізано. Ми працювали над тим, щоб більшість функцій Minimal API, якими ви сьогодні користуєтеся, підтримувалися RDG і, отже, сумісні з нативним AOT.

RDG автоматично вмикається у вашому проєкті, коли ви вмикаєте публікацію за допомогою нативного AOT. Ви також можете вручну ввімкнути RDG, навіть якщо не використовуєте нативний AOT, вказавши 

у файлі проєкту.

Це може бути корисно під час початкової оцінки готовності вашого проєкту до нативної AOT або потенційно для скорочення часу запуску вашої програми.

 

Мінімальні API оптимізовано для отримання та повернення корисних даних JSON за допомогою System.Text.Json, тому також застосовуються вимоги сумісності для JSON і рідного AOT. Це вимагає використання  System.Text.Json source generator . Усі типи, які приймаються як параметри для делегатів запитів або повертаються від делегатів запитів у ваших мінімальних API, мають бути налаштовані на JsonSerializerContext зареєстрованому за допомогою ін’єкції залежностей ASP.NET Core, наприклад:

gRPC і нативний AOT

gRPC підтримує нативний AOT у .NET 8. Нативний AOT дозволяє публікувати клієнтські та серверні програми gRPC у вигляді невеликих швидких власних виконуваних файлів. Дізнайтеся більше про gRPC і нативний AOT у відповідних документах.

Бібліотеки та нативний АОТ

Багато поширених бібліотек, які ви любите використовувати у своїх проєктах ASP.NET Core сьогодні, матимуть певні проблеми сумісності під час використання в проєкті, націленому на власний AOT. Популярні бібліотеки часто покладаються на динамічні можливості відображення .NET для перевірки та виявлення типів, умовного завантаження бібліотек під час виконання та генерування коду на льоту для реалізації їх функціональних можливостей. Як було сказано раніше, така поведінка може спричинити проблеми сумісності з власним AOT, тому ці бібліотеки потрібно буде оновити, щоб працювати з власним AOT за допомогою таких інструментів, як генератори джерел Roslyn .

 

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

Початок роботи з нативним розгортанням AOT в ASP.NET Core

Нативний AOT є опцією публікації. Компіляція AOT відбувається під час публікації програми. Проект, який використовує власну публікацію AOT, використовуватиме JIT-компіляцію під час налагодження або запуску як частини внутрішнього циклу розробника, але є деякі помітні відмінності:

– Деякі функції, несумісні з нативним AOT, вимкнено та створюють винятки під час виконання.

– Аналізатор вихідного коду ввімкнено, щоб виділяти код проєкту, який несумісний із нативним AOT. Під час публікації вся програма, включаючи пакети NuGet, на які посилаються, знову аналізується на сумісність.

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

Перш ніж публікувати проєкти .NET із власним AOT, потрібно встановити такі передумови.

На Windows інсталюйте Visual Studio 2022 і включіть робоче навантаження «Розробка робочого столу за допомогою C++» з усіма компонентами за замовчуванням.

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

 

– Ubuntu (18.04+)

– Alpine (3.15+)

Зауважте, що наразі кросплатформна власна публікація AOT не підтримується, тобто вам потрібно виконати публікацію на тому самому типі платформи, що й передбачувана ціль, наприклад, якщо розгортання націлено на Linux, виконайте публікацію на Linux. Контейнери Docker можуть бути зручним способом увімкнення кросплатформної публікації, приклад чого можна знайти в репозиторії dotnet-docker .

Власні програми AOT, опубліковані ASP.NET Core, можна розгортати та запускати будь-де, де можуть власні виконувані файли. Для цього популярним вибором є контейнери. Власні програми AOT, опубліковані .NET, мають ті самі вимоги до платформи, що й автономні програми .NET, і тому mcr.microsoft.com/dotnet/runtime-depsїх слід використовувати як базовий образ.

Нативні готові для AOT шаблони проєктів

У .NET 8 є два власних шаблони проєктів із підтримкою AOT, які допоможуть вам почати створювати програми ASP.NET Core за допомогою власного AOT.

Шаблон проєкту «ASP.NET Core gRPC Service» оновлено, щоб включити нову опцію «Увімкнути власну публікацію AOT», яка, коли вибрано, налаштовує новий проект для публікації як власної AOT. Це робиться шляхом налаштування <PublishAot>true</PublishAot> у файлі .csproj проєкту.

Існує також абсолютно новий шаблон проєкту «ASP.NET Core Web API (native AOT)», який створює проєкт, більш безпосередньо зосереджений на сценаріях, налаштованих на хмару, перш за все API. Цей шаблон попередньо налаштовано для власного AOT і відрізняється від наявного шаблону проєкту «Web API» таким чином:

– Використовує лише мінімальні API, оскільки MVC ще не сумісний з AOT

– Використовує нове API WebApplication.CreateSlimBuilder, щоб гарантувати, що за замовчуванням увімкнено лише основні функції, мінімізуючи розмір розгорнутої програми

– Налаштовано лише для прослуховування HTTP, оскільки трафік HTTPS зазвичай обробляється вхідною службою в хмарних розгортаннях

– Не включає профіль запуску для роботи під IIS або IIS Express

– Вмикає генератор джерела серіалізатора JSON

– Включає зразок «Todos API» замість зразка прогнозу погоди

Ви можете створити новий проєкт Web API, налаштований на публікацію як нативний AOT, використовуючи dotnet CLI:

Ось вміст Program.cs у проєкті, створеному за допомогою нового шаблону «ASP.NET Core Web API (native AOT)»:

Нативний заклик до дії AOT

Власне розгортання AOT підходить не для всіх програм, але в сценаріях, коли переваги, які пропонує нативний AOT, є переконливими, воно може мати величезний вплив. Хоча це лише початок, ми хотіли б, щоб ви спробували власну підтримку AOT для ASP.NET Core у .NET 8 і поділіться будь-яким відгуком, залишивши коментар тут або зареєструвавши проблему на GitHub . Обов'язково прочитайте поточні відомі проблеми щодо сумісності ASP.NET Core і рідної AOT.

У .NET 8 разом із функціями ASP.NET Core, описаними тут, автентифікацією JWT, перевіркою параметрів і доступом до даних ADO.NET для SQLite та PostgreSQL, усе було оновлено для сумісності з рідною AOT. Ми з нетерпінням чекаємо, що екосистема .NET продовжить використовувати більше бібліотек і функцій для нативного AOT.

Повний стек UI з Blazor

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

Blazor у .NET 8 тепер підтримує такі нові можливості:

– Статична візуалізація на стороні сервера: розміщуйте компоненти Blazor як кінцеві точки ASP.NET Core, які рендерять статичний HTML у відповідь на запити, щоб вміст рендерився негайно без необхідності завантажувати будь-який клієнтський код. Також обробляйте запити форм за допомогою вбудованих компонентів форми Blazor і зручної моделі програмування на основі подій.

– Покращена навігація та обробка форм: Blazor автоматично покращить спосіб завантаження сторінок і обробки запитів форм шляхом перехоплення цих запитів і програмного внесення виправлень вмісту, відтвореного сервером, у DOM. Нема потреби повторно завантажувати раніше отримані веб-ресурси, і наявний стан DOM зберігається. Ваша програма виглядає швидко та плавно, як односторінкова програма, навіть якщо вона все ще виконує статичний рендеринг на стороні сервера.

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

– Увімкнути інтерактивність для кожного компонента або сторінки: увімкніть інтерактивне відтворення на основі Blazor Server або Blazor WebAssembly для окремих компонентів або сторінок за допомогою нової директиви Razor – @rendermode. Ви платите лише за інтерактивність, як-от встановлення з’єднання WebSocket або завантаження середовища виконання .NET WebAssembly, де воно використовується.

– Автоматичний вибір режиму візуалізації під час виконання: автоматично перемикайте користувачів із сервера на клієнт під час виконання, щоб покращити час завантаження програми та масштабованість. Компонент спочатку рендериться в інтерактивному режимі за допомогою Blazor Server, тоді як середовище виконання .NET WebAssembly завантажується у фоновому режимі. Під час майбутніх візитів компонент автоматично перемикається на використання Blazor WebAssembly, щоб отримати швидкий час початкового завантаження та менше навантаження на сервери.

Більше вбудованих компонентів і можливостей Blazor

Blazor також містить багато нових вбудованих компонентів і можливостей, які підвищують продуктивність і допомагають швидко виконувати роботу.

Blazor тепер постачається з QuickGrid, швидким і функціональним компонентом сітки даних для обробки найпоширеніших потреб даних. QuickGrid може завантажувати строго типізовані дані з різноманітних джерел даних, включаючи Entity Framework Core, і ви можете швидко під'єднати QuickGrid до наявної моделі даних за допомогою нового скаффолдера Blazor CRUD. Він підтримує сортування, фільтрацію, сторінку та віртуалізацію. Перегляньте демонстраційний сайт QuickGrid , щоб побачити компонент у дії.

Blazor також тепер підтримує розділи, які є виходами для вмісту, який можна заповнити іншими компонентами за допомогою нових компонентів SectionOutlet та SectionContent. Розділи - це чудовий спосіб визначити точки доступу в макеті вашого додатку, які потім можна налаштувати на окремих сторінках.

Маршрутизація в Blazor також отримала значне оновлення в .NET 8. Маршрутизатор Blazor тепер може маршрутизувати до іменованих елементів за допомогою стандартних фрагментів URL-адреси, і тепер ви можете використовувати більшість функцій маршрутизації ASP.NET Core під час визначення маршрутів сторінок Blazor, як-от визначення обмежень маршруту.

Покращення .NET WebAssembly

Виконання вашого коду .NET на WebAssembly з браузера значно покращено в .NET 8. Ваш .NET код працює набагато швидше завдяки новому середовищу виконання на основі Jiterpreter, яке забезпечує часткову підтримку компіляції just-in-time (JIT) для WebAssembly. З новим середовищем виконання компоненти рендеряться на 20% швидше, а десеріалізація JSON відбувається вдвічі швидше!

Середовище виконання .NET WebAssembly також підтримує багато нових типів редагування за допомогою гарячого перезавантаження, включаючи повний паритет із можливостями гарячого перезавантаження CoreCLR і редагування загальних типів.

Новий зручний для мережі формат пакування для програм Blazor WebAssembly, який називається WebCIL, спрощує розгортання, видаляючи всі біти, специфічні для Windows, із ваших збірок .NET і перепаковуючи їх у файли WebAssembly. За допомогою WebCIL ви можете впевнено розгортати свої програми Blazor WebAssembly.

Новий шаблон Blazor Web App

Почати роботу з усіма новими функціями Blazor у .NET 8 легко за допомогою нового шаблону проєкту Blazor Web App. Це ваше єдине місце для всіх ваших потреб у веб-розробці.

Шаблон Blazor Web App містить зручні параметри для:

– Тип автентифікації: швидко налаштуйте автентифікацію за допомогою ASP.NET Core Identity з інтерфейсом користувача, повністю реалізованим за допомогою компонентів Blazor.

–  Інтерактивний режим візуалізації: виберіть, які інтерактивні режими візуалізації ви хочете ввімкнути: сервер, WebAssembly або обидва з автоматичним.

– Інтерактивне розташування: визначте, чи хочете ви, щоб уся ваша програма була інтерактивною, чи лише окремі компоненти та сторінки.

– Додайте зразки сторінок: виберіть, щоб включити кілька зразків сторінок, щоб розпочати роботу, або просто почніть із порожнього проєкту.

Щоб спробувати створити свій перший вебдодаток Blazor Web App за допомогою .NET 8, просто перейдіть на сторінку https://blazor.net і натисніть «Почати» , щоб розпочати навчання Blazor.

Новий Blazor scaffolder (прев’ю)

Ви можете швидко розпочати роботу зі статичним рендерингом сервера Blazor і QuickGrid, щоб відображати дані з бази даних за допомогою нового скаффолдера Blazor, який тепер доступний з останньою версією Visual Studio Preview. Ви можете використовувати Blazor scaffolder, клацнувши правою кнопкою миші на проєкт в Solution Explorer і вибравши Add > New Scaffolded Item, а потім вибравши Razor Components using Entity Framework (CRUD).

Скаффолдер Blazor генерує основні сторінки створення, читання, оновлення та видалення (CRUD) на основі моделі даних Entity Framework Core. Ви можете створювати окремі сторінки або всі сторінки CRUD за один раз. Ви вибираєте клас моделі та DbContext, що слід використовувати, за потреби створюючи новий DbContext.

Потім до вашого проєкту буде додано створені компоненти Blazor, щоб увімкнути операції CRUD у вибраному класі моделі.

Зверніть увагу, що ці сторінки базуються на візуалізації на стороні сервера, тому вони не підтримуються під час роботи на WebAssembly.

Згенерований компонент Index.razor QuickGrid використовується для відображення даних, тому ви можете легко налаштувати спосіб відображення даних і ввімкнути інтерактивність, щоб скористатися перевагами багатьох його функцій.

Ось приклад того, як виглядають компоненти скаффолдера під час роботи програми:

Типові атрибути для MVC

Атрибути MVC, які раніше вимагали параметрів Type, тепер доступні як загальні атрибути для набагато чистішого синтаксису.

Наприклад, тепер ви можете вказати тип відповіді для дії контролера API таким чином:

Ви можете знайти повний список нових загальних атрибутів для MVC у примітках до релізу.

Кінцеві точки API ідентифікації

ASP.NET Core тепер надає кінцеві точки API для взаємодії з ASP.NET Core Identity. Ці кінцеві точки забезпечують програмний доступ до функціональних можливостей для реєстрації та входу користувачів, що спрощує налаштування автентифікації для браузера та мобільних клієнтських програм. Кінцеві точки можна використовувати як для аутентифікації на основі файлів cookie, так і для автентифікації на основі маркерів. Перегляньте публікацію в блозі Джеремі Лікнесса про те, що нового в ідентифікації в .NET 8, щоб дізнатися все про те, як налаштувати та використовувати ці нові кінцеві точки.

Покращене прив’язування форм для мінімальних API і проміжного програмного забезпечення для захисту від підробки

ASP.NET Core додає підтримку проміжного програмного забезпечення для захисту від підробки, яке підтримує перевірку маркерів захисту від підробки в запитах у всіх реалізаціях фреймворку (Blazor, мінімальні API, MVC). Крім цього, зв’язування форм у мінімальних API також покращено завдяки підтримці зв’язування складних типів із вхідних даних форми, використовуючи ту саму логіку зв’язування, яку спільно використовує Blazor.

Перепідключення SignalR із збереженням стану

SignalR тепер може зменшити відчутний час простою для клієнтів, коли відбувається тимчасове роз'єднання мережевого з'єднання, наприклад, при перемиканні мереж або короткочасній втраті зв'язку. Ви можете налаштувати SignalR на повторне підключення з урахуванням стану, яке налаштує клієнта та сервер на повторне відтворення повідомлень, які могли бути надіслані, коли з’єднання не було. SignalR автоматично подбає про буферизацію повідомлень і відстеження того, які повідомлення вже отримані.

Підтримка ключових служб при ін'єкційній залежності

ASP.NET Core тепер підтримує використання ключових служб під час ін’єкції залежностей (іноді їх називають «Keyed DI»). Keyed DI дозволяє мати кілька реалізацій певної служби, які відрізняються за допомогою зручної для розробника назви. Наприклад, ви можете мати підключення до бази даних для профілів користувачів під назвою «UserProfiles» і інше для вмісту кошика під назвою «ShoppingCarts».

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

Реєстрація та використання сервісів із ключами інтуїтивно зрозумілі та гнучкі. Ось короткий огляд того, як це працює:

Реєстрація ключових послуг:

 

Сервіси з ключем реєструються в колекції сервісів за допомогою унікальних ключів:

Цей підхід дозволяє асоціювати один і той самий інтерфейс з різними реалізаціями, кожна з яких ідентифікується унікальним ключем.

Використання ключових служб:

Ключові служби підтримуються в контролерах, мінімальному API та SignalR.

Щоб скористатися підтримкою нових ключових служб, додайте цільовий параметр до атрибута [FromKeyedServices(“keyName”)].

Наприклад, ось приклади використання ключових служб у контролерах і мінімальних API:

У контролерах MVC:

У мінімальних API:

Подібним чином у мінімальних налаштуваннях API ін’єкція кількох ключових служб у кінцеві точки спрощена:

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

Метрики

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

ASP.NET Core тепер надає широкі показники часу виконання за допомогою System.Diagnostics.Metrics , нового крос-платформного API, розробленого в тісній співпраці зі спільнотою OpenTelemetry .

Ці нові показники вносять багато покращень порівняно з наявними лічильниками подій:

– Нові види вимірювань за допомогою лічильників, датчиків і гістограм.

– Потужні звіти з багатовимірними значеннями.

– Інтеграція в ширшу нативну хмарну екосистему шляхом узгодження зі стандартами OpenTelemetry.

Ви можете прочитати все про нові показники, доступні в ASP.NET Core, і про те, як їх інтегрувати у ваші системи моніторингу, у документації про показники ASP.NET Core .

Популярним способом використання показників є Grafana, хмарний інструмент візуалізації даних OSS. Команда .NET опублікувала інформаційні панелі Grafana, створені на основі нових показників. Інформаційні панелі дозволяють у режимі реального часу бачити статус ваших програм ASP.NET Core.

Завантажте інформаційні панелі безпосередньо з .NET team @ grafana.com і дізнайтеся більше на .NET Grafana dashboards .

Транспортування іменованих каналів

ASP.NET Core тепер надає транспорт іменованих каналів для міжпроцесного зв’язку (IPC) у Windows. Іменовані канали добре інтегруються з безпекою Windows для контролю доступу клієнта до каналу. Перегляньте документацію ASP.NET Core про зв’язок між процесами за допомогою gRPC , щоб дізнатися все про налаштування IPC за допомогою іменованих каналів або сокетів домену Unix.

Кешування виводу на основі Redis

ASP.NET Core у .NET 8 додає підтримку використання Redis як розподіленого кешу для кешування вихідних даних. Кешування вихідних даних забезпечує гнучкий спосіб кешування HTTP-відповідей із сервера. Використання Redis для зберігання кешу забезпечує узгодженість між серверними вузлами через спільний кеш, який переживає окремі серверні процеси.

Оснащення маршруту

Маршрутизація запитів є ключовою частиною будь-якої вебпрограми. Нові функції інструментів для маршрутів у Visual Studio роблять роботу з маршрутами ASP.NET Core простішою, ніж будь-коли раніше. Ці функції включають:

– Підсвічування синтаксису маршруту

– Доповнення редактора для відповідності назв параметрів і маршрутів

– Доповнення редактора для обмежень маршруту

– Аналізатори маршрутів і виправлення типових синтаксичних помилок

Наприклад, ось як виглядають маршрути з .NET 7:

А ось як вони виглядають у .NET 8:

Ви можете прочитати все про нові функції інструментів для маршрутів у дописі в блозі Джеймса Ньютона-Кінга ASP.NET Core Route Tooling Enhancements in .NET 8 .

Покращення дебагування

Потужний дебагер .NET відіграє вирішальну роль у розробці будь-якої програми .NET, і ASP.NET не є винятком. У .NET 8 ми покращили можливість візуалізації налагодження для типів, які часто використовуються в програмах ASP.NET Core, щоб дебагер відразу відкривав найважливішу інформацію.

Наприклад, ось як виглядає перевірка HttpContext за допомогою .NET 7:

 

Ось як це виглядає з .NET 8, де найважливіші значення видно одразу:

Ознайомтеся з усіма новими вдосконаленнями налагодження ASP.NET у публікації Джеймса Ньютона-Кінга про вдосконалення налагодження в .NET 8 .

JavaScript SDK і система проєктів

Часто під час роботи з ASP.NET Core вам також потрібно працювати з JavaScript та екосистемою JavaScript. Поєднання світу .NET і JavaScript може бути складним завданням. Новий SDK для JavaScript і система проєктів у Visual Studio спрощують використання .NET із зовнішніми фреймворками JavaScript. JavaScript SDK забезпечує інтеграцію MSBuild для створення, запуску, налагодження, тестування та публікації коду JavaScript або TypeScript разом із кодом .NET. Ви можете легко інтегрувати такі популярні інструменти створення JavaScript, як WebPack, Rollup, Parcel, esbuild та інші.

Ви можете швидко почати використовувати ASP.NET Core з Angular, React і Vue за допомогою наданих шаблонів Visual Studio:

Ці шаблони доступні як для JavaScript, так і для TypeScript і використовують найновіший інтерфейсний інструмент JavaScript CLI для створення клієнтської програми, тож ви завжди будете в курсі останньої версії.

Ви можете скористатися діалоговим вікном «Install New npm Packages», щоб легко знайти та встановити залежності npm:

Коли ви створюєте свій проєкт JavaScript, JavaScript SDK встановить будь-які залежності пакетів npm. Потім ви можете запустити програму з Visual Studio або в командному рядку за допомогою dotnet run. У Visual Studio ви отримуєте розширену підтримку налагодження коду .NET і JavaScript.

Ви також можете використовувати Visual Studio Test Explorer, щоб виявити та запустити свої тести:

Ви можете дізнатися більше про спільну роботу з .NET і JavaScript у Visual Studio в документах Visual Studio для JavaScript.

І ще багато іншого!

Це лише приклад того, що нового в ASP.NET Core для .NET 8. Щоб отримати повний список, перегляньте примітки до випуску ASP.NET Core у .NET 8.

Оновити наявний проєкт

Щоб оновити наявну програму ASP.NET Core з .NET 7 до .NET 8, виконайте дії, описані в розділі Перехід з ASP.NET Core 7.0 на 8.0

Щоб оновити наявну програму ASP.NET Core з .NET 8 RC2 до .NET 8, оновіть усі посилання на пакет ASP.NET Core до 8.0.0.. У Blazor Web Apps також слід замінити попередні атрибути режиму візуалізації новою директивою  @rendermode:

– Додайте @using static Microsoft.AspNetCore.Components.Web.RenderMode до вашого файлу _Imports.razor

– Замініть @attribute [RenderModeInteractiveServer] на @rendermode InteractiveServer

– Замініть @attribute [RenderModeInteractiveWebAssembly]на @rendermode InteractiveWebAssembly

– Замініть@attribute [RenderModeInteractiveAuto] на @rendermode InteractiveAuto

Це воно! І ви готові користуватися перевагами .NET 8.

Дивіться також повний список критичних змін у ASP.NET Core для .NET 8.

.NET 8 на Azure

.NET 8 уже розгорнуто та готово до використання з усіма вашими улюбленими службами Azure, включаючи службу додатків Azure, функції Azure та статичні веб-програми Azure. Почніть працювати з .NET 8 на Azure вже сьогодні!

Легко створюйте хмарні програми за допомогою .NET Aspire і ASP.NET Core

.NET 8 представляє інтегрований підхід до хмарних додатків через .NET Aspire, створений з використанням надійних можливостей ASP.NET Core. Ця співпраця пропонує розробникам ASP.NET знайоме середовище для використання наявних навичок, водночас користуючись перевагами продуманого стеку, розробленого для стійкості, спостережливості та конфігурованості в хмарі. .NET Aspire плавно покращує ASP.NET Core, включаючи такі основні хмарні компоненти, як телеметрія, стратегії стійкості, керування конфігураціями та готові перевірки справності. Для плавного переходу до хмарної розробки за допомогою інструментів, які ви знаєте і яким довіряєте, ознайомтеся з анонсом .NET Aspire і дізнайтеся, як це може оптимізувати розробку ваших програм у хмарі.

Дякуємо!

Дякуємо всім у спільноті, хто допоміг зробити цей реліз .NET 8 можливим! Цей реліз являє собою кульмінацію багатьох проблем GitHub, запитів, коментарів щодо відгуків про дизайн та оновлень документації, внесених багатьма членами спільноти .NET. Без вас ми б не досягли цього!

Ми сподіваємося, що вам сподобається цей випуск ASP.NET Core у .NET 8. Ми з нетерпінням чекаємо почути про ваш досвід роботи з ним. Надсилайте нам будь-які ваші відгуки щодо цього релізу на GitHub.

Ще раз дякую та щасливого кодування!

C# Dev Kit - тепер загальнодоступне

Радо повідомляємо про загальну доступність C# Dev Kit, розширення коду Visual Studio, яке покращує процес розробки на C#  для Linux, macOS та Windows.

Подяка зусиллям спільноти!

 

З моменту першого попереднього перегляду в червні було отримано як кількісні дані, так і неоціненні відгуки спільноти, які допомогли сформувати цей продукт. Було вирішено близько 350 проблем, про які переважно повідомляла спільнота. Ці вдосконалення охоплюють як покращення якості, так і роз'яснення сценаріїв. Завдяки активній участі користувачів було зроблено понад 300 цілеспрямованих удосконалень, що дозволило зробити розширення більш надійним і безпечним. Ці спільні зусилля стали вирішальними у рішенні перейти від попереднього перегляду до загальної доступності та розпочати офіційну підтримку для підписників Visual Studio.

Що таке C# Dev Kit?

C# Dev Kit використовує основні можливості мови C# і надає розробникам додаткові можливості для продуктивної роботи. Хоча ці основні функції вже стали загальнодоступними, додаткові можливості, що підтримують .NET MAUI та Unity, все ще перебувають у стадії попереднього перегляду, використовуючи C# Dev Kit. Ці розширення продовжують отримувати відгуки та покращувати робочі процеси розробки для MAUI та Unity у VS Code.

Переглядайте корисну інформацію у цьому відео!

Майбутні плани щодо C# Dev Kit

Сьогоднішній офіційний запуск - це лише початок, оскільки надалі планується випускати оновлення розширення щомісяця, прислухаючись до відгуків користувачів та працюючи над покращенням продуктивності, надійності та додаванням нових функцій для підтримки розробки на C# у VS Code. Якщо ви бажаєте отримувати оновлення раніше, підпишіться на канал попередніх випусків, де будуть публікуватися виправлення та анонси нових функцій в міру їх розробки.

Будь ласка, діліться своїми відгуками, повідомляйте про нові проблеми за допомогою коду VS або здійснюйте пошук наявних удосконалень і проблем, а також ставте "великий палець вгору" або надавайте додатковий контекст проблеми, щоб допомогти розставити пріоритети.

Дізнатися більше

Якщо ви хочете дізнатися більше про C# Dev Kit, ви можете відвідати кілька чудових сесій на Ignite та .NET Conf у листопаді або ознайомитися з оновленою документацією C# VS Code та інструкціями з початку роботи. Спробуйте нове середовище C# з C# Dev Kit вже сьогодні!

 

Встановити C# Dev Kit

C# Dev Kit – тепер загальнодоступний

Сьогодні ми раді повідомити про загальну доступність C# Dev Kit, розширення Visual Studio Code, яке надає покращений досвід розробки на C# для Linux, macOS і Windows.

Зусилля спільноти – дякуємо!

З моменту попереднього прев’ю в червні ми отримали дані, що піддаються кількісному вимірюванню, і безцінні відгуки спільноти, які сформували цей продукт. Було розглянуто приблизно 350 питань, про які нам в основному повідомляла спільнота. Ці покращення варіюються від покращення якості до уточнення сценарію. Ваша активна участь призвела до понад 300 цілеспрямованих покращень, які зробили розширення надійнішим і надійнішим. Ці спільні зусилля мали вирішальне значення для нашого рішення перейти від попереднього перегляду до загальної доступності та започаткувати офіційну підтримку для передплатників Visual Studio.

Що таке C# Dev Kit?

C# Dev Kit використовує основні служби мови C# і забезпечує додаткову продуктивність для розробників. Хоча ці основні функції продуктивності зараз загальнодоступні, додаткові можливості, які підтримують .NET MAUI та Unity , все ще перебувають у версії прев’ю, використовуючи C# Dev Kit. Ці розширення продовжують отримувати користь від відгуків і покращують ваші робочі процеси розробки для MAUI та Unity у VS Code.

Перегляньте відео 

Що далі для C# Dev Kit

Сьогоднішній офіційний запуск — це лише початок, оскільки ми продовжуватимемо прислухатися до ваших відгуків і працювати над покращенням продуктивності, надійності та додаванням функцій для підтримки вашої розробки C# у VS Code з оновленнями розширення щомісячно. Якщо ви хочете отримати перші частини, підпишіться на канал прев’ю, де ми будемо додавати виправлення та попередній перегляд нових функцій у міру їх розробки.

Будь ласка, поділіться своїм відгуком, повідомивши про нові проблеми через код VS або здійснивши пошук серед наявних удосконалень і проблем, а також поставте «великий палець» або додайте контекст до проблеми, щоб допомогти нам визначити пріоритети.

Вивчайте більше

 

Якщо ви хочете дізнатися більше про C# Dev Kit, ви можете відвідати кілька чудових сесій, які відбудуться на Ignite та .NET Conf у листопаді, або ознайомитися з нашою оновленою документацією C# VS Code та документацією «Початок роботи». Спробуйте нове середовище C# із C# Dev Kit сьогодні!

Оновлення ASP.NET Core в .NET 8 Preview 6

.NET 8 Preview 6 вже доступна і містить багато нових чудових покращень в ASP.NET Core.

Ось короткий огляд новинок цієї попередній версії:

Покращено налагодження під час запуску

Blazor.

Прив'язка та валідація моделі форми з рендерингом на стороні сервера

Покращена навігація сторінками та обробка форм

Збереження наявних DOM-елементів за допомогою потокового рендерингу

Можливість вказати режим рендерингу компонентів на сайті виклику

Інтерактивний рендеринг з Blazor WebAssembly

Покращення розділів

Каскадний запит значень рядків до компонентів Blazor

Опція шаблону Blazor Web App для включення серверної інтерактивності

Консолідація шаблону Blazor

Метрики

Тестування метрик у додатках ASP.NET Core

Нові, покращені та перейменовані лічильники

Розробка API

Підтримка зв'язування складних форм у мінімальних API

Сервери та проміжне програмне забезпечення

Буферизація відповідей ядра HTTP.sys

Вихідний кеш на основі Redis

Щоб дізнатися більше про заплановані роботи над ASP.NET Core для .NET 8, дивіться повний опис ASP.NET Core для .NET 8 на GitHub.

Розпочнімо.

Щоб почати роботу з ASP.NET Core в .NET 8 Preview 6, встановіть .NET 8 SDK.

Якщо ви використовуєте Visual Studio на Windows, рекомендується встановити останню версію Visual Studio 2022 preview. Якщо ви використовуєте Visual Studio Code, ви можете спробувати нове розширення C# Dev Kit. Якщо ви використовуєте macOS, то можете працювати за допомогою Visual Studio для Mac 17.6.1, увімкнувши функцію preview для .NET 8 у Налаштуваннях.

Оновлення наявного проєкту

Щоб оновити наявний додаток ASP.NET Core з .NET 8 Preview 5 до .NET 8 Preview 6:

Оновіть цільовий фреймворк вашого додатка до net8.0.

Оновіть усі посилання на пакунок Microsoft.AspNetCore.* до версії 8.0.0-preview.6.*.

Оновіть усі посилання на пакунок Microsoft.Extensions.* до версії 8.0.0-preview.6.*.

Дивіться також повний список суттєвих змін в ASP.NET Core для .NET 8.

Покращений досвід налагодження під час запуску

У минулій попередній версії було представлено поліпшення налагодження для HttpContext. У .NET 8 Preview 6 покращено налагодження для типу WebApplication.

WebApplication - це спосіб за замовчуванням для налаштування та запуску додатків ASP.NET Core у Program.cs. Атрибути налагодження були застосовані до WebApplication, щоб виділити важливу інформацію, таку як налаштовані кінцеві точки, проміжне програмне забезпечення та значення IConfiguration у налагоджувачі вашого IDE.

.NET 7

.NET 8

Дивіться ASP.NET Core Налагодження GitHub для отримання додаткової інформації про покращення налагодження в .NET 8.

 

Blazor

Зв'язування та валідація моделі форми з рендерингом на стороні сервера

Новий режим рендерингу на стороні сервера Blazor тепер може моделювати зв'язування і перевіряти значення постів HTTP-форм.

Щоб прив'язати дані із запиту форми, застосуйте атрибут [SupplyParameterFromForm] до властивості компонента. Дані в запиті, які відповідають назві властивості, будуть прив'язані до цієї властивості. Властивість може бути примітивним типом, складним типом, колекцією або словником. Також підтримується перевірка на стороні сервера за допомогою анотацій даних.

 

Movie.cs

Якщо на сторінці є кілька форм, їх можна розрізнити за допомогою параметра Name, і ви можете використовувати властивість Name на [SupplyParameterFromForm], щоб вказати, з якої форми ви хочете зв'язати дані.

Вам більше не потрібно налаштовувати компонент CascadingModelBinder, щоб увімкнути прив'язку моделей. Тепер він налаштований для вас автоматично.

Покращена навігація сторінками та обробка форм

Тепер Blazor покращує навігацію сторінками та обробку форм шляхом перехоплення запиту, щоб застосувати відповідь до наявного DOM, максимально зберігаючи його. Покращення дозволяє уникнути необхідності повного завантаження сторінки й забезпечує користувачам значно простіший інтерфейс, подібний до односторінкового додатка (SPA), навіть якщо додаток все ще рендериться на стороні сервера.

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

Збереження наявних DOM-елементів за допомогою потокового рендерингу

Потоковий рендеринг Blazor тепер зберігає наявні DOM-елементи під час потокової передачі оновлень на сторінку, що забезпечує швидший і простіший користувацький інтерфейс.

Можливість вказати режим рендерингу компонентів на сайті виклику

Тепер ви можете вказати режим рендерингу для екземпляра компонента за допомогою атрибута директиви @rendermode. Режим рендерингу буде застосовано до компонента та його дочірніх елементів. Наприклад, 

<Counter @rendermode="@RenderMode.Server" />

Щоб увімкнути використання call site @rendermode, переконайтеся, що у файлі проєкту встановлено версію мови Razor 8.0. Це буде оброблено внутрішньо у фреймворку і не буде необхідним, починаючи з наступного релізу. Для цього відредагуйте файл .csproj вашого проєкту, додавши в перший елемент <PropertyGroup> наступний рядок: <RazorLangVersion>8.0</RazorLangVersion>

Інтерактивний рендеринг з Blazor WebAssembly

Тепер ви можете увімкнути інтерактивний рендеринг компонентів за допомогою Blazor WebAssembly. Хоча ця опція ще не доступна у шаблоні вебпрограми Blazor, ви можете увімкнути її вручну.

Щоб увімкнути підтримку режиму рендерингу WebAssembly у вашому проєкті Blazor, додайте відповідні служби викликом app.Services.AddRazorComponents().AddWebAssemblyComponents() і додайте режим рендерингу WebAssembly викликом app.MapRazorComponents<App>().AddWebAssemblyRenderMode(). Будь-які компоненти, які ви хочете рендерити на WebAssembly, потрібно буде завантажити разом з усіма їхніми залежностями у браузер. Вам потрібно буде створити окремий проєкт Blazor WebAssembly для створення будь-якого специфічного коду для WebAssembly і посилатися на нього з вашого додатка Blazor.

Ви можете вказати режим інтерактивного рендерингу WebAssembly для компонента, додавши атрибут [RenderModeWebAssembly] до визначення компонента або вказавши @rendermode="@RenderMode.WebAssembly" у екземплярі компонента. Компоненти, які ви налаштували на рендеринг у WebAssembly, за замовчуванням також будуть попередньо рендеритися з сервера, тому переконайтеся, що ваші компоненти будуть коректно рендеритися в обох середовищах, або вимкніть попередній рендеринг при визначенні режиму рендерингу: [RenderModeWebAssembly(prerender: false)] або @rendermode="@(new WebAssemblyRenderMode(prerender: false)).

Ось приклад, що демонструє, як налаштувати інтерактивність на основі WebAssembly для компонента Counter, який виводиться зі сторінки Index .

Зауважте, що наразі існує обмеження, згідно з яким компоненти з маршрутами мають бути визначені у тій самій збірці, що й компонент App, переданий до MapRazorComponents<App>(), тому наразі їх не можна визначити у клієнтській збірці. Ця проблема буде вирішена у майбутньому оновленні.

Покращення розділів Blazor

Ми зробили наступні покращення у взаємодії розділів Blazor з іншими функціями Blazor:

Каскадні значення: Каскадні значення тепер потраплятимуть у вміст секції з місця визначення вмісту, а не з місця його виведення у виводі секції.

Межі помилок: Необроблені винятки тепер оброблятимуться межами помилок, визначеними навколо вмісту секції, а не навколо виводу секції.

Потоковий рендеринг: Використання потокового рендерингу для вмісту секції тепер визначається компонентом, у якому визначено вміст секції, а не компонентом, у якому визначено вивід секції.

Каскадний запит значень рядків до компонентів Blazor

 

Тепер ви можете отримувати значення параметрів рядка запиту в будь-якому компоненті, а не тільки в компонентах @page, використовуючи атрибут [SupplyParameterFromQuery]. Наприклад:

[SupplyParameterFromQuery]

public int PageIndex { get; set; }

Більше не потрібно додавати атрибут [Parameter] до будь-якої властивості, яка оголошує [SupplyParameterFromQuery].

Опція шаблону Blazor Web App для включення серверної інтерактивності

Шаблон Blazor Web App тепер надає опцію у Visual Studio для включення інтерактивності за допомогою режиму серверного рендерингу:

Ця ж опція вже доступна з командного рядка:

dotnet new blazor --use-server

Консолідація шаблону Blazor

У рамках об'єднання різних моделей хостингу Blazor в єдину модель в .NET 8, також консолідовано кількість шаблонів проєктів Blazor. У цій попередній версії видалено шаблон Blazor Server і опцію "ASP.NET Core hosted" з шаблону Blazor WebAssembly. Обидва ці сценарії будуть представлені у вигляді опцій при використанні нового шаблону Blazor Web App.

 

Метрики

Тестування метрик у додатках ASP.NET Core

У попередній версії .NET 8 було представлено метрики ASP.NET Core. Тепер стало простіше тестувати метрики в додатках ASP.NET Core.

ASP.NET Core використовує API IMeterFactory для створення та отримання показників. IMeterFactory особливо корисний для модульного тестування, коли кілька тестів можуть виконуватися паралельно, і ви хочете зібрати дані тільки для вашого тесту. 

 

У прикладі нижче показано, як використовувати IMeterFactory і MetricCollector<T> (спрощений спосіб збору даних показників) у функціональному тесті ASP.NET Core:

Нові, покращені та перейменовані лічильники

ASP.NET продовжує покращувати підтримку метрик, додаючи нові лічильники та вдосконалюючи наявні. Це дозволить зробити додатки ASP.NET Core помітними в інформаційних панелях звітів і увімкнути користувацькі сповіщення.

Нові лічильники в цьому випуску:

routing-match-success і routing-match-failure повідомляють про те, як запит було направлено в додатку. Якщо запит успішно збігається з маршрутом, лічильник містить інформацію про шаблон маршруту і про те, чи був це запасний маршрут.

diagnostics-handler-exception додано до проміжного програмного забезпечення обробки винятків. Лічильник повідомляє про те, як обробляються необроблені винятки, і містить інформацію про назву винятку та результат обробника.

http-server-unhandled-requests - це новий лічильник у хостингу ASP.NET Core. Він повідомляє, коли HTTP-запит досягає кінця конвеєра проміжного програмного забезпечення, не бувши обробленим додатком.

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

Покращені лічильники:

kestrel-connection-duration тепер містить протокол з'єднання HTTP і протокол TLS.

signalr-http-transport-current-connections тепер містить тип транспортного з'єднання.

Окрім того, на основі тестування ASP.NET Core за допомогою хмарних інструментів, було перейменовано всі лічильники ASP.NET Core, щоб надати в назву більше інформації. Лічильники було перейменовано, щоб їх можна було ідентифікувати лише за назвою та зменшити ймовірність конфліктів імен. Наприклад, request-duration було перейменовано на http-server-request-duration.

Розробка API

Підтримка зв'язування складних форм у мінімальних API

У .NET 8 Preview 4 розширено підтримку зв'язування форм у мінімальних API для обробки певних параметрів на основі форм без використання атрибута FromForm. Це було обмежено типами параметрів, включаючи IFormCollection, IFormFile і IFormFileCollection. Мінімальні API тепер підтримують прив'язку до форми для складніших сценаріїв, зокрема:

Колекцій, таких як List і Dictionary

 

Складних типів, таких як Todo або Project

У наведеному нижче прикладі показано мінімальну кінцеву точку, яка зв'язує багатокомпонентний ввід форми зі складним об'єктом. Він також показує, як використовувати служби захисту від підробок в ASP.NET для підтримки генерації та перевірки токенів від підробок в мінімальних API. Ключові моменти, на які слід звернути увагу в цьому прикладі, включають

Цільовий параметр має бути анотований атрибутом [FromForm], щоб відрізнити його від параметрів, які мають бути прочитані з JSON body.

Прив'язка до типів record  наразі не підтримується, тому складні типи мають бути реалізовані як клас.

Рекурсивне зв'язування не підтримується, тому тип Todo не містить рекурсивних посилань.

Сервери та проміжне програмне забезпечення

Буферизація відповідей ядра HTTP.sys

Тепер ви можете ввімкнути буферизацію відповідей на основі ядра при використанні HTTP.sys за допомогою параметра EnableKernelResponseBuffering. Ця опція може покращити час відповіді, особливо при написанні великих відповідей з великою кількістю дрібних записів до клієнта з великою затримкою. У відповідних сценаріях це може значно покращити час відповіді з хвилин (або повної відсутності) до секунд.

Кешування виводу на основі Redis

Кешування виводу було введено в .NET 7 і дозволяє кешувати й відтворювати відповіді цілком, зменшуючи час обробки на сервері. За замовчуванням, кешовані відповіді зберігаються в процесі роботи, тому кожен вузол сервера має окремий ізольований кеш, який втрачається при перезапуску серверного процесу. Тепер доступна можливість використовувати бекенд Redis для кешування вихідних даних, що забезпечує узгодженість між вузлами сервера за допомогою спільного кешу, який не залежить від окремих серверних процесів.

 

Щоб налаштувати кешування виводу на основі Redis, додайте посилання на пакет Microsoft.Extensions.Caching.StackExchangeRedis, а потім налаштуйте необхідні служби, викликавши app.Services.AddStackExchangeRedisOutputCache(...). Доступні опції конфігурації ідентичні наявним опціям розподіленого кешування на основі Redis. Ви можете надати власний сервер Redis або скористатися послугами хостингу, наприклад, Azure Cache для Redis.

та

 

Ми раді повідомити, що ми випустили нову версію .NET Upgrade Assistant у Visual Studio, яка робить ваше оновлення до найновішої версії .NET framework ще простішим!

.NET Upgrade Assistant - це інструмент, який допоможе вам оновити ваш додаток до найновішої версії .NET та перейти зі старих платформ, таких як Xamarin Forms та UWP, на новіші пропозиції. У лютому ми випустили розширення Visual Studio для цього інструменту, а зараз вийшла нова версія з багатьма покращеннями та новими функціями. Переконайтеся, що у вас увімкнено автоматичне оновлення для цього інструменту, щоб отримати найкращі результати. У Visual Studio | Extensions | Manage Extensions знайдіть .NET Upgrade Assistant у розділі Installed і переконайтеся, що позначку Автоматично оновлювати це розширення встановлено. Запустіть Visual Studio від імені адміністратора, щоб внести ці зміни, якщо потрібно.