Трансформуйте свій бізнес за допомогою розумних .NET-додатків на базі Azure та ChatGPT

За допомогою ChatGPT ви можете розкрити весь потенціал штучного інтелекту у своїх програмах .NET і гарантувати неймовірний досвід для користувачів від використання природної мови. ChatGPT — це більше, ніж просто інструмент; це те, що кардинально змінює те, як ми отримуємо доступ до даних і аналізуємо їх. Незалежно від того, використовуєте ви Azure, SQL Server або будь-яке інше джерело даних, ви можете легко інтегрувати ChatGPT у свої проєкти .NET і почати створювати інтелектуальні програми вже сьогодні.

У цій публікації я дам короткий огляд того, що таке інтелектуальні програми. Потім, використовуючи зразок програми, я покажу, як за допомогою комбінації служб Azure, таких як Azure OpenAI Service і Azure Cognitive Search, ви можете створювати власні інтелектуальні програми .NET.

TLDR

Ви найкраще вчитеся на практичному досвіді? Ознайомтеся з репозиторієм і приступайте прямо зараз!

Створіть свій власний розумний додаток .NET

Що таке розумні програми?

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

Bing Chat є прикладом інтелектуальної програми.

ШІ лежить в основі Bing Chat. Bing Chat використовує штучний інтелект для обробки складних запитів, узагальнення релевантної інформації з різних джерел і створення відповідей.

Створюйте інтелектуальні програми за допомогою .NET

Тепер, коли ви маєте уявлення про те, що таке інтелектуальні програми, давайте подивимося на приклад програми, створеної за допомогою .NET, Azure і ChatGPT.

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

Припустімо, у вас є внутрішня корпоративна база знань, яка містить інформацію про посади, плани охорони здоров’я та інші ділові документи.

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

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

Архітектура програми

Вихідний код програми знаходиться на GitHub. Нижче наведено основні компоненти програми.

Інтерфейс користувача

Інтерфейс програми є статичною веб-програмою Blazor WebAssembly . Цей інтерфейс приймає запити користувачів, направляє запити до серверної частини програми та відображає згенеровані відповіді. Якщо ви працюєте з клієнтськими програмами на мобільному телефоні чи настільному комп’ютері, .NET MAUI також буде хорошим варіантом для цього компонента.

Сервер програми

Бекенд програми — це мінімальний API ASP.NET Core . Серверна частина містить статичну веб-програму Blazor і те, що організовує взаємодію між різними службами. Послуги, які використовуються в цій програмі, включають:

– Azure Cognitive Search – індексує документи з даних, що зберігаються в обліковому записі Azure Storage. Це робить документи доступними для пошуку.

– Служба Azure OpenAI – надає моделі ChatGPT для створення відповідей. Крім того, Semantic Kernel використовується в поєднанні зі службою Azure OpenAI Service для організації більш складних робочих процесів ШІ.

– Azure Redis Cache – кешує відповіді. Це зменшує затримку під час створення відповідей на схожі запитання та допомагає керувати витратами, оскільки вам не потрібно робити інший запит до служби Azure OpenAI.

Надання ресурсів і середовища для розробника

З усіма згаданими послугами процес початкового налаштування може здатися складним. Однак ми спростили цей процес за допомогою Azure Developer CLI . Якщо ви не хочете встановлювати будь-яку залежність, ми також можемо вам допомогти. Просто відкрийте репозиторій у GitHub Codespaces і використовуйте Azure Developer CLI, щоб надати свої послуги.

Використання ChatGPT у ваших документах

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

Перш ніж почати спілкуватися в чаті зі своїми документами, ви захочете мати базу знань, до якої можна зробити запит. Швидше за все, у вас вона вже є. Для цього прикладу програми ми зробили просту базу знань. У каталозі даних програми є набір PDF-документів. Щоб завантажити їх у Azure Storage та індексувати в Azure Cognitive Search, ми створили консольну програму C#.

Консольна програма C# виконує такі дії:

1. Використовує Azure Form Recognizer для вилучення тексту з кожного документа.

2. Розбиває документи на менші уривки. (нарізка)

3. Створює новий документ PDF для кожного з уривків.

4. Завантажує уривок до облікового запису сховища Azure.

5. Створює індекс у Azure Cognitive Search.

6. Додає документи до індексу когнітивного пошуку Azure.

 

Чому PDF-файли розбиваються на частини?

Моделі OpenAI, такі як ChatGPT, мають обмеження на токени. Щоб отримати додаткові відомості про обмеження маркерів, перегляньте довідковий посібник із квот і обмежень служби Azure OpenAI.

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

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

Спілкуйтеся зі своїми даними

Коли ви налаштуєте свою базу знань, настав час поспілкуватися з нею.

Запит до бази знань починається з того, що користувач вводить запитання у веб-програмі Blazor. Потім запит користувача направляється до ASP.NET Core Minimal Web API.

Всередині веб-інтерфейсу API кінцева точка chat обробляє запит.

api.MapPost(“chat”, OnPostChatAsync);

Щоб обробити запит, ми застосовуємо шаблон, відомий як Retrieval Augmented Generation, який робить наступне:

1. Запитує в базі знань відповідні документи

2. Використовує відповідні документи як контекст для створення відповіді

Запит до бази знань

Запити до Бази знань відбуваються за допомогою когнітивного пошуку Azure. Хоча когнітивний пошук Azure не розуміє природну мову, надану користувачем. На щастя, ми можемо використовувати ChatGPT, щоб допомогти перекласти природну мову в запит.

 

Використовуючи семантичне ядро, ми створюємо метод, який визначає шаблон підказки та додає історію чату та запитання користувача як додатковий контекст для створення запиту Azure Cognitive Search.

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

Коли ви запускаєте функцію семантичного ядра, вона надає складену команду моделі Azure OpenAI Service ChatGPT, яка генерує відповідь.

З огляду на питання “Що входить до мого плану Northwind Health Plus, чого немає в стандарті?”, сформований запит може виглядати так: “Покриття плану Northwind Health Plus

Після створення запиту скористайтеся клієнтом Azure Cognitive Search, щоб зробити запит до індексу, що містить ваші документи.

На цьому етапі когнітивний пошук Azure поверне результати, які містять документи, які найбільше відповідають вашому запиту. Результати можуть виглядати так:

Northwind_Health_Plus_Benefits_Details-108.pdf: ви повинні надати Northwind Health Plus з копією EOB для первинного страхування, а також копію заяви, яку ви подали до свого первинного страхування. Це дозволить нам визначити переваги, доступні вам за Northwind Health Plus. Важливо зазначити, що Northwind Health Plus не покриває жодних витрат, які вважаються відповідальністю Основного покриття.

Benefit_Options-3.pdf: Плани також охоплюють профілактичні послуги, такі як мамографія, колоноскопія та інші скринінги на рак. Northwind Health Plus пропонує більш повне покриття, ніж Northwind Standard. Цей план пропонує покриття екстрених служб, як у мережі, так і поза мережею, а також покриття психічного здоров’я та зловживання психоактивними речовинами. Northwind Standard не пропонує покриття послуг екстреної допомоги, психічного здоров’я та токсикоманія, а також послуги поза мережею

Створення відповіді

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

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

Чи жорстко ми кодуємо відповіді в запиті?

НЕ жорстко. Приклади в запиті слугують вказівками для моделі для створення відповіді. Відоме як кількакратне навчання.

Коли ви запускаєте функцію семантичного ядра, вона надає скомпонований запит для моделі Azure OpenAI Service ChatGPT, яка генерує відповідь.

Після деякого форматування відповідь повертається до веб-програми та відображається. Результат може виглядати приблизно так:

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

Створюйте власні інтелектуальні програми

Ми з нетерпінням чекаємо майбутнього інтелектуальних програм у .NET.

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

 

Створіть свій власний розумний додаток .NET

 

Source

Анонс C# 12

C# 12 доступний вже сьогодні! Ви можете отримати його, завантаживши .NET 8, останню версію Visual Studio або C# Dev Kit від Visual Studio Code.

Для існуючих проектів вам також потрібно вказати, що ви хочете змінити мовну версію. Ви можете змінити мовну версію, змінивши TargetFramework на .NET 8:

C# 12 підвищує продуктивність розробників завдяки спрощеному синтаксису та пришвидшенню виконання. Ви можете ознайомитися з подробицями про кожну функцію в статті Що нового в C# 12 на MS Learn. Стаття “Що нового” містить посилання на оновлення документації по C# на MS Learn, які відображають нові можливості.

Спрощення коду

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

У C# 12 введено вирази колекцій, первинні конструктори для всіх класів і структур, синтаксис для псевдонімів будь-якого типу та параметри за замовчуванням для лямбда-виразів, які спрощують ваш код.

Вирази колекцій

 

До C# 12 створення колекцій вимагало різного синтаксису для різних сценаріїв. Ініціалізація List вимагала іншого синтаксису, ніж int[] або Span. Ось лише декілька способів створення колекцій:

Вирази колекцій мають уніфікований синтаксис:

Ви не тільки можете використовувати єдиний синтаксис, але й компілятор створює для вас швидкий код. У багатьох випадках компілятор встановлює ємність колекції та уникає копіювання даних.

А якщо цього виявиться недостатньо – ви можете використовувати оператор new spread для включення елементів однієї або декількох колекцій або перечислювальних виразів у вираз колекції:

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

Ми дуже зацікавлені у відгуках щодо можливої майбутньої роботи над виразами колекцій. Ми розглядаємо можливість розширення виразів колекцій за рахунок словників та підтримки var (природних типів) у майбутній версії C#.

Як і багато інших нових можливостей C#, аналізатори можуть допомогти вам перевірити нову функцію та оновити ваш код:

Дізнайтеся більше про вирази збору у цій статті на MS Learn.

Первинні конструктори для будь-якого класу або структури

 

У C# 12 розширено можливості первинних конструкторів для роботи з усіма класами та структурами, а не лише із записами. Первинні конструктори дозволяють вам визначати параметри конструктора під час оголошення класу:

Найпоширеніші способи використання первинного параметра конструктора

• Як аргумент для виклику конструктора base().

• Для ініціалізації поля або властивості члена.

• Посилання на параметр конструктора у члені екземпляру.

• Для усунення шаблонів при ін’єкції залежностей.

Ви можете розглядати первинний параметр конструктора як параметр, який є доступним для всього оголошення класу.

Ви можете додавати первинні конструктори до будь-якого типу: class, struct, record class та record struct. Параметри первинних конструкторів у class і struct є доступними для всього визначення class або struct. Ви можете використовувати параметри для ініціалізації полів або властивостей, або в тілі інших членів. При використанні з типами record компілятор генерує загальнодоступну властивість для кожного первинного параметра конструктора. Ці властивості є лише одними з багатьох членів, які автоматично генеруються для типів record.

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

Дізнайтеся більше про первинні конструктори у цій статті. Щоб дізнатися більше про використання первинних конструкторів для записів і не-записів, перегляньте Підручник: Вивчення первинних конструкторів.

Псевдонім будь-якого типу

 

Псевдонімизація типів – це зручний спосіб прибрати складні сигнатури типів з вашого коду. Починаючи з C# 12, у директивах alias можна using додаткові типи. Наприклад, у більш ранніх версіях C# ці псевдоніми не працюють:

Що нового в ідентифікації в .NET 8

У квітні 2023 року я писав про зобов’язання команди ASP.NET Core покращити автентифікацію, авторизацію та керування ідентифікацією в .NET 8. Представлений нами план включав три основні результати:

– Нові API для спрощення входу та керування ідентифікацією для клієнтських програм, таких як Single Page Apps (SPA) і Blazor WebAssembly.

– Увімкнення автентифікації та авторизації на основі маркерів у ASP.NET Core Identity для клієнтів, які не можуть використовувати файли cookie.

– Покращення в документації.

Усі три результати з’являтья разом із .NET 8. Крім того, ми змогли додати новий інтерфейс ідентифікації для веб-програм Blazor, який працює з обома новими режимами візуалізації, сервером і WebAssembly.

Давайте розглянемо кілька сценаріїв, уможливлених новими змінами в .NET 8. У цій публікації блогу ми розглянемо:

– Захист простого серверного веб-API

– Використання нового інтерфейсу ідентифікатора Blazor

– Додавання зовнішнього логіна, наприклад Google або Facebook

– Захист програм Blazor WebAssembly за допомогою вбудованих функцій і компонентів

– Використання токенів для клієнтів, які не можуть використовувати файли cookie

Давайте розглянемо найпростіший сценарій використання нових функцій ідентифікації.

Базовий сервер веб-API

Простий спосіб використання нової авторизації — увімкнути її в базовій програмі Web API. Цю ж програму також можна використовувати як серверну частину для Blazor WebAssembly, Angular, React та інших односторінкових веб-програм (SPA). Якщо ви починаєте з проекту ASP.NET Core Web API у .NET 8, який включає OpenAPI, ви можете додати автентифікацію за кілька кроків.

Ідентифікація є “опціональною”, тож залишилося додати ще кілька пакунків:

– Microsoft.AspNetCore.Identity.EntityFrameworkCore– пакет, який забезпечує інтеграцію EF Core

– Пакет для бази даних, яку ви бажаєте використати, наприклад Microsoft.EntityFrameworkCore.SqlServer(у цьому прикладі ми використаємо базу даних у пам’яті)

 

Ви можете додати ці пакети за допомогою менеджера пакетів NuGet або командного рядка. Наприклад, щоб додати пакети за допомогою командного рядка, перейдіть до теки проєкту та виконайте такі команди dotnet:

 

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

 

Додайте новий клас під назвою AppDbContext, який успадковує від IdentityDbContext:

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

Щоб налаштувати ідентифікатор для програми, відкрийте файл Program.cs. Налаштуйте ідентифікатор на використання автентифікації на основі файлів cookie та ввімкніть перевірку авторизації, додавши наступний код після виклику WebApplication.CreateBuilder(args):

 

Налаштуйте базу даних EF Core. Тут ми використаємо базу даних у пам’яті та назвемо її «AppDb». Вона використовується тут для демонстрації, тому можна легко перезапустити програму та перевірити потік, щоб зареєструватися та ввійти (кожний запуск розпочинатиметься з новою базою даних). Перехід на SQLite збереже користувачів між сеансами, але вимагає належного створення бази даних за допомогою міграцій, як показано в цьому посібнику з початку роботи з EF Core. Ви можете використовувати інші реляційні постачальники, такі як SQL Server, для свого робочого коду.

 

Налаштуйте ідентифікацію для використання бази даних EF Core та відкрийте кінцеві точки ідентифікації:

 

Позначте маршрути для кінцевих точок ідентифікації. Цей код слід розмістити після виклику builder.Build():

Тепер програма готова до автентифікації та авторизації! Щоб захистити ендпоінт, використовуйте метод розширення .RequireAuthorization(), де ви визначаєте маршрут авторизації. Якщо ви використовуєте рішення на основі контролера, ви можете додати атрибут [Authorize]до контролера або дії.

Щоб протестувати програму, запустіть її та перейдіть до інтерфейсу користувача Swagger. Розгорніть захищений ендпоінт, оберіть «випробувати» та виберіть «Виконати». Ендпоінт отримує повідомлення 404 – not found, що, мабуть, є більш безпечним, ніж повідомлення, 401 – not authorized оскільки воно не показує, що кінцева точка існує.

Тепер розгорніть /register і заповніть свої облікові дані. Якщо ви введете недійсну адресу електронної пошти або неправильний пароль, результат міститиме помилки перевірки.

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

Успішна реєстрація призводить до відповіді 200 – OK. Тепер ви можете розгорнути /login та ввести ті самі облікові дані. Зауважте, що для цього прикладу є додаткові параметри, які можна видалити. Обов’язково встановіть useCookies true. Успішний вхід призводить до відповіді 200 – OK з файлом cookie в заголовку відповіді.

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

Деякі веб-клієнти можуть не включати файли cookie в заголовок за умовчанням. Якщо ви використовуєте інструмент для тестування API, вам може знадобитися ввімкнути файли cookie в налаштуваннях. JavaScript API fetch не включає файли cookie за замовчуванням. Ви можете ввімкнути їх, встановивши значення credentials як  include в параметрах. Подібним чином, HttpClient запущений в програмі Blazor WebAssembly потребує HttpRequestMessage для включення облікових даних, наприклад:

Далі перейдемо до веб-програми Blazor.

Інтерфейс ідентифікації Blazor

Велика мета нашої команди, якої ми змогли досягти, полягала в тому, щоб реалізувати користувальницький інтерфейс ідентифікації, який включає параметри реєстрації, входу та налаштування багатофакторної автентифікації в Blazor. Інтерфейс користувача вбудовано в шаблон, коли ви вибираєте параметр «Індивідуальні облікові записи» для автентифікації. На відміну від попередньої версії інтерфейсу ідентифікації, яка була прихована, якщо ви не хотіли її налаштувати, шаблон генерує весь вихідний код, щоб ви могли змінювати його за потреби. Нова версія створена на основі компонентів Razor і працює як із серверними програмами, так і з програмами WebAssembly Blazor.

Нова веб-модель Blazor дозволяє вам налаштувати, чи інтерфейс користувача відображатиметься на стороні сервера чи клієнта, що працює в WebAssembly. Якщо ви обираєте режим WebAssembly, сервер усе одно оброблятиме всі запити на автентифікацію та авторизацію. Він також створить код для спеціальної реалізації AuthenticationStateProvider, яка відстежує стан автентифікації. Постачальник використовує  клас PersistentComponentState для попереднього відтворення стану автентифікації та збереження його на сторінці. PersistentAuthenticationStateProvider у клієнтській програмі WebAssembly використовує компонент для синхронізації стану автентифікації між сервером і браузером. Постачальник стану також може бути названий PersistingRevalidatingAuthenticationStateProvider під час роботи з автоматичною інтерактивністю або IdentityRevalidatingAuthenticationStateProvider для інтерактивності сервера.

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

Додайте зовнішній логін

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

По-перше, вам потрібно буде зареєструвати свою програму на веб-сайті соціальної мережі. Наприклад, щоб додати логін Twitter, перейдіть на портал розробників Twitter і створіть нову програму. Вам потрібно буде надати певну базову інформацію, щоб отримати облікові дані клієнта. Після створення програми перейдіть до налаштувань програми та натисніть «редагувати» під час автентифікації. Укажіть «нативний додаток» для типу додатка, щоб потік працював правильно, і ввімкніть «запитувати електронні листи від користувачів». Вам потрібно буде надати URL-адресу зворотного виклику. У цьому прикладі ми використаємо URL-адресу зворотного виклику https://localhost:5001/signin-twitter за умовчанням для шаблону веб-програми Blazor. Ви можете просто замінити цю адресу, щоб відповідати URL-адресі вашої програми (тобто замінити 5001 своїм власним портом). Також зверніть увагу на ключ і секрет API.

Далі додайте до своєї програми відповідний пакет автентифікації. Існує список постачальників соціальної автентифікації OAuth 2.0 для ASP.NET Core, який підтримується спільнотою, із багатьма варіантами на вибір. Ви можете комбінувати кілька зовнішніх входів за потреби. Для Twitter я додам пакет AspNet.Security.OAuth.Twitter.

 

З командного рядка в кореневому каталозі проєкту сервера виконайте цю команду, щоб зберегти ключ API (ідентифікатор клієнта) і секрет.

 

Нарешті, налаштуйте вхід в Program.cs, замінивши цей код:

з цим кодом:

Файли cookie є кращим і найбезпечнішим підходом для впровадження ASP.NET Core Identity. Токени підтримуються за потреби та потребують налаштування IdentityConstants.BearerScheme. Токени є пропрієтарними, а потік на основі токенів призначений для простих сценаріїв, тому він не реалізує стандарти OAuth 2.0 або OIDC.

Що далі? Вірите чи ні, ви закінчили. Цього разу, коли ви запускаєте програму, сторінка входу автоматично визначить зовнішній логін і надасть кнопку для його використання.

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

Захист програм Blazor WebAssembly

Основною мотивацією для додавання нових ідентифікаційних API було  бажання полегшити розробникам захист їхніх браузерних програм, включаючи Single Page Apps (SPA) і Blazor WebAssembly. Немає значення, чи використовуєте ви вбудований постачальник ідентифікації, спеціальну систему входу чи хмарну службу, як-от Microsoft Entra, кінцевим результатом буде ідентифікація, яка або автентифікована за допомогою претензій і ролей, або не автентифікована. У Blazor ви можете захистити компонент Razor, додавши атрибут [Authorize] до компонента або до сторінки, на якій розміщено компонент. Ви також можете захистити маршрут, додавши .RequireAuthorization()метод розширення до визначення маршруту.

Повний вихідний код для цього прикладу доступний у сховищі зразків Blazor.

Тег AuthorizeView забезпечує простий спосіб обробки вмісту, до якого користувач має доступ. Доступ до стану автентифікації можна отримати через властивість context. Зверніть увагу на наступне:

Привітання буде показано всім. У випадку Blazor WebAssembly, коли клієнту може знадобитися асинхронна автентифікація через виклики API, вміст Authorizing буде показано під час запиту та вирішення стану автентифікації. Потім, залежно від того, пройшли ви автентифікацію чи ні, ви побачите своє ім’я або повідомлення про те, що ви не автентифіковані. Як саме клієнт дізнається, чи ви автентифіковані? Ось де з’являється AuthenticationStateProvider.

Сторінка App.razor загорнута в провайдера CascadingAuthenticationState. Цей провайдер відповідає за відстеження стану автентифікації та надання до нього доступу для решти програми. AuthenticationStateProvider впроваджується в провайдера та використовується для відстеження стану. AuthenticationStateProvider також вводиться в компонент AuthorizeView. Коли стан автентифікації змінюється, постачальник сповіщає компонент AuthorizeView, і вміст оновлюється відповідно.

 

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

 

В Program.cs додав обробник до HttpClient і використав фабрику клієнтів, щоб налаштувати спеціальний клієнт для автентифікації.

 

AuthUrl - це URL-адреса сервера ASP.NET Core, на якому доступні API ідентифікації. Далі я створив CookieAuthenticationStateProvider, який успадковує AuthenticationStateProvider і перевизначає метод GetAuthenticationStateAsync. Основна логіка виглядає так:

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

Як програма дізнається, коли стан змінився? Ось як виглядає вхід із Blazor WebAssembly за допомогою ідентифікаційного API:

Після успішного входу викликається метод NotifyAuthenticationStateChanged базового класу AuthenticationStateProvider, щоб повідомити провайдера про зміну стану. Йому передається результат запиту нового стану автентифікації, щоб він міг перевірити наявність файлу cookie. Після цього провайдер оновить компонент AuthorizeView, і користувач побачить автентифікований вміст.

Токени

У рідкісних випадках, коли ваш клієнт не підтримує файли cookie, API входу надає параметр для запиту токенів. Видається спеціальний токен (який є власністю платформи ідентифікації ASP.NET Core), який можна використовувати для автентифікації наступних запитів. Токен передається в хедері  Authorization як маркер токена. Також надається токен оновлення. Це дозволяє вашій програмі запитувати новий токен, коли закінчується термін дії старого, не змушуючи користувача знову входити в систему. Токени не є стандартними веб-токенами JSON (JWT). Це рішення було прийнято навмисно, оскільки вбудована ідентифікація призначена в основному для простих сценаріїв. Параметр маркера не призначений для повнофункціонального постачальника послуг ідентифікації або сервера маркерів, а замість цього є альтернативою параметру cookie для клієнтів, які не можуть використовувати файли cookie.

Не впевнені, чи потрібен вам сервер токенів чи ні? Прочитайте документ, який допоможе вам вибрати правильне рішення ідентифікації ASP.NET Core. Шукаєте більш просунуте рішення ідентифікації? Прочитайте наш список рішень для керування ідентифікацією для ASP.NET Core.

Документи та зразки

Третій результат – документація та зразки. Ми вже представили нову документацію та будемо додавати нові статті та зразки, коли наблизимось до релізу .NET 8. Слідкуйте за релізом № 29452 – документація та зразки для ідентифікації в .NET 8, щоб відстежувати прогрес. Будь ласка, використовуйте випуск, щоб надіслати додаткову документацію або зразки, які ви шукаєте. Ви також можете посилатися на конкретні проблеми для різних документів і залишати там свої відгуки.

Висновок

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

Дізнайтеся більше про нові функції ідентифікації в документації ASP.NET Core .

Source

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 сьогодні!

 

 

Ми раді повідомити вам про найновіші функції та вдосконалення, доступні в .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<TEnum>

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

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

 

 

JsonConverter.Type

 

 

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

 

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

 

Перевантаження методів 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), тому наразі використовується:

Exception: Collection was modified after the enumerator was instantiated.

та

 

Ми раді повідомити, що ми випустили нову версію .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 від імені адміністратора, щоб внести ці зміни, якщо потрібно.

 

Що нового в цій версії

Ми раді повідомити, що в цьому випуску додано підтримку нових сценаріїв для різних платформ, фреймворків тощо! Ось деякі з нових покращень:

 

• Підтримка .NET 8.
• Оновлення з Xamarin.Forms до .NET MAUI.
• Оновлення для функцій Azure.
• Оновлення з UWP на WinUI.
• Підтримка ARM64.

Оновлення та вдосконалення

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

 

• Покращено спосіб оновлення пакунків NuGet за допомогою Помічника з оновлення.
• Оновлений сценарій Incremental для використання YARP 2.0.
• Покращено обробку помилок, тепер всі збої та попередження можна побачити у вікні прогресу для кожного компонента проекту.
• Численні інфраструктурні оновлення рушія інструменту, які покращили продуктивність та загальну якість оновлень.
• Підтримка проектів у стилі SDK, які використовують System.Web. Раніше веб-проекти, які були вручну перетворені в SDK-стиль, але все ще використовували System.Web, не могли бути оновлені інкрементально і розглядалися як проекти сімейства Core. Тепер Upgrade Assistant розглядає їх як проекти .NET Framework і дозволяє оновлювати їх поетапно, що є найкращим способом оновлення веб-додатків з .NET Framework до найновіших версій .NET.
• WinForms - додано обробку для випадків, коли певні API зі старої версії не підтримуються в новій версії .NET.
• ASP.NET - додано покращення щодо того, як проекти оновлюються за лаштунками.

 

 

Exception: Collection was modified after the enumerator was instantiated.

 

 

Ми раді повідомити про офіційний запуск версії 8.2 інструментарію .NET Community Toolkit! Ця нова версія містить покращення швидкості роботи як під час виконання, так і в генераторах вихідного коду MVVM Toolkit, нові засоби для усунення помилок, що підвищують вашу результативність, нові функції на основі запитів користувачів та багато іншого!

Що входить до інструментарію .NET Community Toolkit?

Інструментарій .NET Community Toolkit містить наступні бібліотеки:

• CommunityToolkit.Common

• CommunityToolkit.Mvvm (також відомий як "Microsoft MVVM Toolkit")

• CommunityToolkit.Diagnostics

• CommunityToolkit.HighPerformance

Ці компоненти також широко використовуються в деяких програмах для роботи з вхідними повідомленнями, які постачаються з Windows, зокрема у Microsoft Store і програма "Photos"!

Для більш детальної інформації про історію розвитку інструментарію .NET Community Toolkit, ось посилання на попередній пост з анонсом версії 8.0.0.

 

Перелік основних змін, які включені в нову версію 8.2 інструментарію .NET Community Toolkit.

Користувацькі атрибути для [RelayCommand]

Продовжуючи роботу, виконану у випуску 8.1.0, і як було запропоновано на GitHub, новий випуск 8.2.0 набору інструментів MVVM Toolkit містить підтримку користувацьких атрибутів при використанні [RelayCommand]. Знову ж таки, було використано нативне field: і property: C#, щоб вказати цільові значення користувацьких атрибутів. Завдяки цьому ви тепер маєте повний контроль над атрибутами для всіх згенерованих членів, коли використовуєте [RelayCommand] для створення команди MVVM.

Наприклад, це особливо корисно, коли ви використовуєте модель подання, яка має підтримувати серіалізацію JSON, і вам потрібно явно ігнорувати згенеровану властивість. Ви можете використовувати підтримку нового  field: і property: наступним чином:

Після цього будуть створені наступні елементи:

Як і слід було очікувати, згенерована властивість DoWorkCommand має вказаний атрибут над нею! І, звичайно ж, підтримуються атрибути з будь-якою кількістю конструкторів та іменованих параметрів. Ви також можете використовувати просто field:, property:  поле:або будь-яку їх комбінацію

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

Нові змінені перехоплення [ObservableProperty]

Відносно поширеним сценарієм у MVVM є наявність деякої властивості "вибраний елемент", яка представляє, наприклад, поточного вибраного користувача або вкладену модель представлення. Коли значення цієї властивості змінюється, нерідко доводиться вносити певні корективи до старого та нового екземплярів. Наприклад, встановити якусь "вибрану" властивість, або підписатися на подію, і так далі.

Раніше це був сценарій, де використання [ObservableProperty] не було ідеальним, оскільки воно не мало необхідної інфраструктури, щоб легко впровадити таку логіку для виконання необхідних змін стану для старих і нових значень, що встановлюються. Щоб виправити це, починаючи з версії 8.2 MVVM Toolkit, для всіх полів [ObservableProperty] генеруються два нові змінені перехоплення властивостей.

 

Наприклад, розглянемо наступний код:

Тепер буде згенеровано такий код:

Зверніть увагу на два нові методи "OnPropertyNameChanging" і "Changed", що генеруються, тепер вони також приймають попереднє значення. Ці два методи є простими у використанні перехопленнями для додавання коду, який спрацьовує при кожній події зміни властивості й може змінювати як старе, так і нове значення, що встановлюється. Наприклад, ви можете використовувати їх наступним чином:

І це все, що вам потрібно! Вибрана модель перегляду тепер завжди буде коректно повідомлятися як вибрана. Вам більше не потрібно повертатися до використання ручної властивості у подібних сценаріях, [ObservableProperty] тепер має вбудовану підтримку і для цього!

Примітка: MVVM Toolkit автоматично визначить, чи використовуєте ви будь-який з цих методів, щоб максимально оптимізувати кодову структуру. Крім того, виклики методів, які не реалізовані, будуть просто видалені компілятором Roslyn, тому вся ця функція є повністю платною!

Фіксери коду MVVM Toolkit

У попередньому випуску MVVM Toolkit було додано два нових діагностичних аналізатора, які видають попередження при некоректному доступі до поля, позначеного [ObservableProperty], а також при оголошенні типу з [ObservableProperty] і подібними атрибутами, коли доступне використання наслідування. У версії 8.2 ці два аналізатори також містять вбудовані засоби для виправлення коду!

Тобто, коли будь-який з них видає попередження, ви можете просто навести курсор на лампочку IntelliSense, вибрати виправлення коду й автоматично застосувати всі необхідні зміни, щоб повернути ваш код до правильного вигляду! Вони також підтримують групові виправлення, тому ви можете виправити всі помилки одним клацанням!

Тут ви можете побачити новий інтерфейс виправлення коду у Visual Studio з попереднім переглядом змін, а також опціями застосування виправлення до потрібного вам діапазону

Оптимізація генератора вихідного коду MVVM Toolkit

Як і кожен випуск, MVVM Toolkit 8.2 також включає деякі покращення продуктивності генераторів вихідних кодів. Цього разу основна увага була приділена оптимізації інкрементних конвеєрів, щоб мінімізувати використання пам'яті й гарантувати, що жодні непотрібні об'єкти не залишаться активними під час паралельних виконань. Ось деякі зміни, які було зроблено для покращення цього:

• Перенесено решту діагностик до аналізаторів (#581): ще дві діагностики з MVVM Toolkit було перенесено до діагностичного аналізатора, який можна запускати паралельно та поза процесом. Це вилучає деякі символи Roslyn з інкрементального конвеєра та покращує загальну продуктивність генератора.

• Попередня обробка символів на початку роботи аналізаторів (#587): усі необхідні символи аналізатора тепер обробляються під час початкового налаштування зворотного виклику, що пришвидшує його виконання у кожному екземплярі компіляції.

Інші зміни та покращення

• Виправлено помилку збірки з VB.NET проєктів (#592): MVVM Toolkit спричиняв помилки збірки з VB.NET проєктів через деякі некоректні властивості MSBuild. Наразі це виправлено.

• Виправлено перенаправлені параметри подвійних атрибутів (#603): перенаправлені атрибути через [ObservableProperty] некоректно відображали цілі значення типів float та double у тип int. Тепер вони передаватимуться коректно зі збереженням початкового типу.

• Виправлено генератори вихідного коду, що обробляють вкладені/загальні типи (#606): виправлено проблему, яка призводила до збою декількох генераторів вихідного коду при використанні Roslyn 4.0 та загальних типів.

• Додано API ArrayPoolBufferWriter<T>.DangerousGetArray() (#616): цей новий API дозволяє легко взаємодіяти між ArrayPoolBufferWriter<T> та старими API, які вимагають масив T[] як параметр (на відміну від Span<T>/Memory<T>).

• Вилучено System.Linq з CommunityToolkit.Diagnostics (#622): за результатами дослідження, проведеного у runtime/#82607, з пакунка Diagnostics повністю вилучено всі посилання на System.Linq. Це покращує підтримку обрізання у збірці та дозволяє заощаджувати більший розмір двійкових файлів у опублікованих збірках (особливо з NativeAOT).

• Підтримка часткових методів з [RelayCommand] (#633): атрибут [RelayCommand] тепер працюватиме коректно, якщо його буде додано над визначенням або частиною реалізації часткового методу.

• Додано підтримку відкритих узагальнених типів у ToTypeString (#639): розширення Type.ToTypeString() тепер коректно обробляє відкриті узагальнені типи. Наприклад, typeof(List<>).ToTypeString() тепер повертатиме "System.Collections.Generic.List<>".

• Додано [MemberNotNull] у встановлювачах [ObservableProperty] (#646): коли це застосовано (тобто коли атрибут є доступним і тип властивості не можна занулити), генератор [ObservableProperty] також генеруватиме необхідні анотації про можливість занулення, щоб гарантувати, що встановлення створеної властивості коректно позначить поля як ініціалізовані. Це розв'язує проблему полів, які показували попередження про недопустимість, навіть якщо згенеровану властивість було встановлено.

• Повні XML-документи для згенерованих членів (#653): усі згенеровані типи та члени тепер оформлено у вигляді повних XML-документів, тож перевірка коду, створеного генераторами вихідного коду MVVM Toolkit, має бути дещо простішою, ніж раніше.

Примітка: у старих версіях Roslyn існує відома проблема з генераторами вихідних кодів, через яку IntelliSense може іноді працювати некоректно для згенерованих елементів (див. #493 і пов'язану з ним проблему відстеження у Roslyn). Ця проблема має бути в основному виправлена в VS 2022 17.6 і вище (або, коли використовується Roslyn 4.6, в тому числі через інші IDE, такі як VS Code і Rider). Якщо ви зіткнулися з цією проблемою, переконайтеся, що ви оновили свій інструментарій до останньої доступної версії.

Інші зміни

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

Почніть вже сьогодні!

Ви можете знайти весь вихідний код у репозиторії GitHub, деякі рукописні документи на MS learn та повні посилання на API на вебсайт браузера .NET API. Якщо ви хочете зробити свій внесок, не соромтеся залишати проблеми або звертатися до команди, щоб повідомити про свій досвід! Щоб стежити за обговоренням у Twitter, використовуйте хештег #CommunityToolkit. Всі ваші відгуки дуже допомагають формувати напрямок розвитку цих бібліотек, тому обов'язково діліться ними!

 

Вдалого кодування!

Exception: Collection was modified after the enumerator was instantiated.

Покращення повідомлень про помилки хоста .NET і можливості підтримки

 

Ви коли-небудь намагалися запустити програму .NET і бачили повідомлення про помилку про те, що вам не вистачає середовища виконання, як-от нижче? Ви коли-небудь засмучувалися повідомленням про те, що вам не вистачає SDK, але ви не знаєте, чому? У рамках .NET 7 Preview 6 ми оновили кілька повідомлень про помилки та команд як dotnet --info, щоб надати більше корисної інформації.

 

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

Ця публікація була написана командою .NET Host. Я розміщую цю публікацію на хостингу, а також є членом команди хостингу. Сподіваюся, я хороший хост.

Контекст

 

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

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

 

Деякі повідомлення про помилки містять посилання на різні сторінки завантаження на веб-сайті .NET . Ці посилання цілодобово отримують великий трафік. Це говорить про те, що це важливий досвід, у який ми повинні інвестувати більше. І ми це робимо. У нас є подібний досвід для .NET Framework, який існує протягом тривалого часу.

Відсутній час виконання

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

Ми оновили наші повідомлення про помилки, щоб мати загальну структуру:

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

 

Ми також перенесли ці оновлення до .NET 6.0.7. Досвід із відсутнім середовищем виконання є важливим, і ми вважаємо, що було б корисно як для кінцевих користувачів, так і для розробників, щоб ці покращення були в нашому останньому випуску LTS .

Інсталяція .NET не знайдена

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

 

Якщо .NET взагалі не інстальовано, запущена програма .NET 7 покаже:

 

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

 

Для додатків графічного інтерфейсу користувача Windows ми внесли подібні зміни до показаної помилки, включивши посилання на документацію та більш чітке викладення відповідної інформації:

Ці зміни покращують попередню поведінку:

Потрібний фреймворк не знайдено

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

 

Запуск програми покаже:

У повідомленні є окремий розділ для важливої ​​інформації, як-от ім’я (Microsoft.AspNetCore.App), версія (7.0.0-preview.4.22251.1) та архітектура (x64) відсутнього фреймворку та розташування, де він знаходиться очікується встановлення. Подібно до помилки, коли .NET взагалі не інстальовано, тут є посилання на документацію та посилання для завантаження, щоб користувач міг вирішити проблему. Знову ж таки, ми прагнемо, щоб більшість користувачів могли вирішити проблему за допомогою посилання для завантаження, але намагаємось включити більш детальну інформацію щодо можливості підтримки.

Для програм графічного інтерфейсу Windows ми знову внесли подібні зміни до показаної помилки:

Так само, як у випадку, коли .NET взагалі не інстальовано, додається посилання на документацію та чітко викладена відповідна інформація.

 

Ці зміни покращують попередню поведінку:

Архітектура

Ви також можете зіткнутися з проблемами під час роботи програми, якщо не встановлено середовище виконання .NET відповідної архітектури. Наприклад, ми часто спостерігаємо це під час запуску програми x64 на машині macOS або Windows Arm64, де встановлено середовище виконання Arm64 .NET, але не x64, або запуск програми x86 на машині Windows x64, де встановлено середовище виконання x64 .NET встановлено, але не x86.

 

Це проявляється як відсутність інсталяції .NET або відсутність необхідного фреймворку залежно від того, чи є інсталяція відповідної архітектури. Щоб допомогти розв'язувати проблеми, пов’язані з різними архітектурами, повідомлення тепер показує архітектуру, наприклад:

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

 

Ми внесли кардинальні зміни в те, як .NET використовує PATH для операційних систем, які підтримують емульовані архітектури (у .NET Core 3.1, .NET 6 і .NET 7). Встановлення .NET оновлюватиме лише змінну середовища PATH для рідної архітектури операційної системи. Наприклад, встановлення x86 (32-розрядної версії) не оновлюватиме файл PATH, якщо встановлено на 64-розрядній машині. Попередня поведінка (стоовно оновлення PATH інсталяцій .NET із емульованою та рідною архітектурою) спричинила значну плутанину клієнтів і поломку продукту. Проблема полягає в тому, що поведінка старої схеми не завжди була передбачуваною. Нова схема на 100% передбачувана та надійна. Ми внесли ті самі зміни в .NET для x64 в операційних системах Arm64 .

Розташування .NET

 

Власний хост для програми .NET шукає середовище виконання .NET на основі змінних середовища, файлів конфігурації (в Unix) або ключів реєстру (в Windows) і добре відомих розташувань за замовчуванням. Можливо, у вас справді встановлено потрібне середовище виконання .NET, але не в місці, визначеному програмою. Щоб полегшити визначення, коли ви можете опинитися в такій ситуації, ми додали до повідомлень про помилки розташування .NET, яке використовує хост. Наприклад, повідомлення про відсутню необхідну структуру показує щось на зразок:

 

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

 

У .NET 7 ми також вимкнули багаторівневий пошук лише для Windows (див. сповіщення про критичні зміни ). Це означає, що хост програми .NET більше не шукає фреймворки в кількох місцях. Наприклад, якщо необхідний фреймворк встановлено у глобально зареєстрованому розташуванні, але змінна середовища DOTNET_ROOT налаштована на встановлення без цього фреймворку, інсталяція, що відповідає значенню DOTNET_ROOT, вважатиметься розташуванням .NET, і ви отримаєте повідомлення про помилку повідомлення про те, що необхідну структуру не знайдено в цьому місці.

Відсутній SDK

 

Для розробників .NET запуск команд .NET SDK є початковою точкою для будь-якої розробки. За замовчуванням використовується останній встановлений SDK, але конкретну версію можна налаштувати за допомогою файлу global.json . У .NET 7, якщо ви спробуєте запустити команду SDK, але не маєте встановленої версії, указаної у файлі global.json, ви побачите помилку, подібну до:

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

Ми вважаємо, що формулювання та макет полегшують перегляд відповідних деталей, порівняно з попередньою поведінкою:

Це оновлення для роботи з відсутнім SDK також було перенесено до .NET 6.0.7. Ми сподіваємося, що новий досвід полегшить розблокування під час розробки.

Рідний хост також надає API для роздільної здатності SDK, який використовується для вирішення MSBuild SDK . У .NET 7 ми оновили цей API, щоб надати більше інформації, наприклад запитану версію SDK. Ми плануємо використати цю інформацію для надання кращого повідомлення про помилку , якщо не вдасться вирішити SDK у таких сценаріях.

dotnet --info

Команда dotnet --info виводить інформацію про інсталяцію .NET і середовище, в якому вона запущена. Це корисно для самодіагностики проблем і для надання інформації під час запиту підтримки.

 

У .NET 7 ми оновили результат, щоб він виглядав так:

Відповідно до оновлених повідомлень про помилки ми очистили макет, видалили непотрібний текст і додали посилання на документацію. Ми також включили архітектуру хоста та будь-який файл global.json, який використовувався для вирішення SDK.

Як згадувалося раніше, ми спостерігали плутанину через різні архітектури або розташування .NET . Щоб допомогти з розумінням таких проблем, ми оновили dotnet --info, щоб перерахувати інсталяції інших архітектур, включаючи їх розташування та, якщо це можливо, спосіб їх реєстрації, а також будь-які змінні середовища DOTNET_ROOT, які впливають на те, як рідний хост виглядає для середовища виконання .NET.

Це був попередній результат:

Повідомлення про помилки SDK

 

Ми виявили деякі повідомлення про помилку SDK, які посилаються на global.json, але не вказують його розташування. Це може дуже засмучувати . Ми сподіваємося покращити цей досвід у пізнішому Прев’ю.

Значок dotnet

У відповідь на чудову пропозицію спільноти ми також додали піктограму до виконуваного файлу dotnet в Windows. Замість значка програми Windows за замовчуванням тепер ви побачите:

Веб-сайт

Веб -сайт .NET є метою для посилань для завантаження. Посилання містять невеликі фрагменти інформації, наприклад, яка потрібна архітектура та версія .NET. Наразі веб-сайт спрямовує користувача на сторінку для певної версії, як для .NET 7. Однак користувачеві потрібно вибирати між кількома завантаженнями.

 

Надалі ми плануємо оновити веб-сайт, щоб за цими посиланнями пропонувалося одне завантаження. Він має відповідати операційній системі, архітектурі та версії .NET запиту. Таким чином, усі користувачі (технічні чи нетехнічні) матимуть простий досвід «натисни та зайди», не потребуючи жодних спеціальних знань.

Висновки

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

 

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

Source

Exception: Collection was modified after the enumerator was instantiated.

Оновлення .NET проектів за допомогою Visual Studio

 

Тепер ви можете оновити будь-яку .NET програму до останньої версії .NET прямо з Visual Studio! Ми раді представити його як розширення Visual Studio, яке дозволить оновити ваші веб- та десктопні додатки на базі .NET Framework або .NET Core. Деякі типи проектів знаходяться в розробці і будуть доступні найближчим часом, дивіться деталі нижче.

 

Навіщо оновлюватись і до якої версії?

 

Якщо ваші програми розроблені на .NET Framework або .NET Core, зараз чудовий час оновити їх до .NET 6 (версія з довгостроковою підтримкою) або .NET 7 (версія зі стандартною підтримкою), які мають набагато кращу продуктивність і надають доступ до найновіших функцій та можливостей. Між .NET Framework та останньою версією .NET відбулися величезні покращення, але навіть якщо ви використовуєте .NET Core 3.1 або більш ранню версію, її підтримка закінчується в грудні 2022 року.

 

The author recommends porting to .NET 6 or .NET 7!

 

Між цими двома версіями .NET 6 має довший час підтримки, а .NET 7 є найновішою, тому має новіші функції. Ми випускаємо нову версію .NET щороку в листопаді, і кожна парна версія підтримується протягом 3 років (довгострокова підтримка, або скорочено LTS). Таким чином, ви можете або залишатися на найновіших передових технологіях і оновлюватись щороку, або переходити з LTS на LTS раз на 2-3 роки.

 

Про Upgrade Assistant

 

Оновлення додатку, особливо з .NET Framework, було складним процесом. Команда продовжує створювати прототипи та вдосконалюватися в цій галузі, щоб спростити оновлення. У минулому ви могли використовувати інструмент Upgrade Assistant CLI або Microsoft Project Migrations. Ваші відгуки було зібрано, велика подяка всім, хто заповнив опитування або залишив коментарі, створив проблеми і запити функцій! Враховуючи ваші відгуки, команда дійшла висновку, що необхідно забезпечити уніфікований досвід оновлення для всіх типів проектів у Visual Studio.

 

Тепер ви зможете оновити будь-який тип .NET-додатків з будь-якої початкової версії (.NET Framework або .NET Core), клацнувши правою кнопкою миші на вашому проекті в Solution Explorer і вибравши "Оновити". Не забудьте спочатку встановити розширення.

Загальна філософія Upgrade Assistant полягає в тому, що він подбає про механіку, але залежно від того, з якого фреймворку і типу проекту ви оновлюєтесь, вам слід очікувати, що вам доведеться виконати деяку ручну пост-обробку. Хоча команда намагається автоматично виправляти зміни, що порушують роботу фреймворку, він не може виявити і виправити всі з них. Тому вам може знадобитися внести деякі додаткові зміни, щоб змусити код компілюватися, а також ретельно протестувати, щоб переконатися, що ваш код продовжує працювати належним чином.

 

Підтримувані типи програм

Ми прагнемо підтримувати кожен тип .NET проектів. Крім того, ми розглядаємо цей інструмент не лише як одноразове оновлення з .NET Framework до .NET 6/7, але й як спосіб оновити ваш додаток до найновішої версії .NET у майбутньому. Окрім зміни цільової версії фреймворку, інструмент зможе модифікувати ваш код, щоб виправити непрацюючі зміни. Це наші плани на майбутнє, а наразі ось що підтримується інструментом в останній версії:

ASP.NET

Class libraries

Console

WPF

WinForms

 

Ці робочі навантаження є паритетними з інструментом Upgrade Assistant CLI.

3. Ви побачите головну сторінку з кількома варіантами оновлення.

Який варіант вибрати, описано в різних типах оновлень.

4. Для цього прикладу я обираю In-place. Side-by-side буде дуже схожим з кількома додатковими кроками. Додаткові можливості side-by-side incremental описані в попередньому пості в блозі.

 

5. Потім вам потрібно вибрати фреймворк, на який ви хочете перейти. Інструмент запропонує лише ті варіанти, які мають сенс для вашого типу проекту. У моєму прикладі це бібліотека класів .NET Framework, тому він також запропонує .NET Standard.

Всі оновлення є прямими, тобто якщо ваш проект, наприклад, вже працює на .NET 6, буде запропоновано лише .NET 7 і новіші версії. Якщо на вашому комп'ютері не встановлено обраний SDK, вам буде запропоновано встановити його на наступному кроці. Просто перейдіть за посиланням і поверніться до оновлення після встановлення SDK. .NET Standard пропонується лише для бібліотек класів, які були орієнтовані на .NET Framework.

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

7. Після натискання кнопки Upgrade selection ви побачите хід оновлення і звіт після його завершення.

 

Підсумок

Тепер ви можете оновлювати свої .NET проекти прямо з Visual Studio.

Source

Exception: Collection was modified after the enumerator was instantiated.