Posted on 9. April 2024

Windows Photos begins previewing a Windows App SDK version to Windows Insiders

Windows Photos починає попередній перегляд версії Windows App SDK для інсайдерів Windows


Ми починаємо розгортати попередню версію програми “Фотографії”, створену за допомогою Windows App SDK (WASDK), для інсайдерів Windows у каналах Canary та Dev на Windows 11. Ця зміна переносить програму “Фотографії” на найновішу платформу для розробки додатків для Windows із сучасним інтерфейсом користувача та іншими покращеннями якості й продуктивності.


У цій версії збережено всі поточні функції та можливості програми “Фотографії”. Однак, зважаючи на значні зміни, ця версія може бути дещо недопрацьованою, оскільки ми продовжуємо вдосконалювати її роботу. Щоб випробувати цю версію, інсайдери Windows 11 на каналах Canary та Dev можуть оновити програму “Фото” до версії 2024.11040.1002.0.


Ми цінуємо ваші коментарі та пропозиції, тому діліться з нами своїми відгуками!

ВІДГУК: надішліть відгук у розділі Feedback Hub (WIN + F) «Програми» > «Фотографії» .

 

Щоб дізнатися більше про Windows App SDK, відвідайте: Створення настільних програм Windows за допомогою Windows App SDK – програми Windows | Microsoft Learn .

 

Source




Posted on 5. April 2024

Transform your business with smart .NET apps powered by Azure and ChatGPT

Трансформуйте свій бізнес за допомогою розумних .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. 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 . Цей шаблон не є основним, що використовується в цьому прикладі, і виходить за рамки цієї публікації. Однак у наступних публікаціях ми розглянемо ці теми більш детально, тож слідкуйте за оновленнями!


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

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


Зображення запитання, яке ставлять у веб-програмі ChatGPT .NET

Запит до бази знань починається з того, що користувач вводить запитання у веб-програмі 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, яка генерує відповідь.


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


Зображення, на якому показано відповіді, згенеровані ChatGPT у веб-програмі .NET

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

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

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

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

 

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


 

Source




Posted on 4. April 2024

Announcing .NET MAUI in .NET 8 Preview 6: Hello VS Code & VS for Mac

Анонс .NET MAUI у .NET 8 Preview 6: Hello VS Code & VS для Mac

.NET MAUI тепер доступний у .NET 8 Preview 6, в якому вирішено 23 важливих проблеми та впроваджено Native AOT для iOS. Крім того, сьогодні ви можете насолоджуватися .NET MAUI в .NET 8, використовуючи нове розширення .NET MAUI для коду Visual Studio, а також з випуском 17.6.1 Visual Studio для Mac.

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

Виправлення та покращення в .NET MAUI

Вирішено декілька важливих проблем, пов’язаних зі шрифтами (#9104, #13239), навігацією (#7698, #15488, #9938), вкладками (#12386, #13239, #6929) та файловим провідником (#11088). Команда також продовжує роботу над покращенням керування пам’яттю та усуненням витоку адрес (#15062, #15303, #15831).

.NET 8 preview 6 представляє Native AOT (попередня компіляція) для iOS. Використовуючи цю функцію попереднього перегляду, ми спостерігаємо зменшення розміру додатків на 30-40% порівняно з Mono. Якщо вас зацікавила можливість досягти кращої продуктивності та зменшення розміру додатків для iOS, ознайомтеся з подробицями у статті про .NET 8 preview 6 у блозі.

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

Представляємо VS Code (Preview)

На сьогодні вже випущено розширення .NET MAUI для Visual Studio Code, що забезпечує однаковий досвід розробки для Windows, macOS та Linux. Щоб дізнатися більше про розширення, прочитайте статтю Медді Монтакіли в блозі, де вона розповідає про нього.

screenshot of Visual Studio Code debugging a .NET MAUI app in an Android emulator

Як оновити

Visual Studio 2022 для Windows тепер містить попередні версії .NET 8 та робоче навантаження .NET MAUI. Завантажте останню попередню версію (17.7 Preview 3), виберіть робоче навантаження .NET Multi-platform App UI, а потім позначте додатковий компонент “.NET MAUI (.NET 8 Preview)”.

Visual Studio installer checkbox for .NET MAUI and .NET 8 previews

Якщо ви використовуєте macOS, то тепер можете програмувати за допомогою Visual Studio для Mac, увімкнувши функцію попереднього перегляду для .NET 8 у Параметрах і встановивши .NET 8 preview 6 з інсталятора.

Enable .NET 8 in Visual Studio 2022 for Mac

Завантажте інсталятор .NET 8 preview 6, а потім встановіть .NET MAUI з командного рядка:

dotnet workload install maui


Поділіться своїми відгуками!

Ваші відгуки та внески в .NET MAUI дуже цінні. Ви можете повідомляти про проблеми, пропонувати функції або надсилати запити у репозиторії GitHub. Також ви можете приєднатися до сервера Discord або слідкувати за командою у Twitter, щоб бути в курсі останніх новин та оновлень.

 

Дякуємо за вашу підтримку і щасливого кодування!

Source



Posted on 16. March 2024

Get started with .NET 8 and AI using new quickstart tutorials

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

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

Вивчайте штучний інтелект за допомогою нових інструкцій зі швидкого запуску .NET

Ми щойно випустили новий набір швидких запусків, які ви можете використовувати з великими мовними моделями OpenAI (незабаром з’явиться ще більше моделей):

У кожному прикладі ви крок за кроком ознайомитеся з кодом, необхідним для виконання теми, за допомогою Azure OpenAI SDK. Дуже скоро ми також додамо версії цих прикладів з використанням Semantic Kernel SDK (ми опублікуємо пост тут, коли вони будуть готові).

Дізнайтеся більше про основні концепції

Якщо ChatGPT, LLM, моделі та OpenAI – це нові для вас терміни, або ви тільки починаєте працювати в цій сфері, ось кілька додаткових ресурсів, які допоможуть вам вивчити основні поняття та дослідити їх краще:

 



.NET | AI | C#
Posted on 14. March 2024

.NET MAUI Community Toolkit 2023 Highlights

Основні моменти .NET MAUI Community Toolkit 2023

 

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

Це був рік, коли

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

У цифрах

 

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

  • 260 комітів: З кожним комітом ми покращували та розширювали функціональність інструментарію.

  • Змінено 521 файл: Відображаючи наш прогрес, ми оновили, покращили та оптимізували 521 файл, щоб забезпечити найвищі стандарти якості.

  • 41 дописувач: Велике вітання нашим активним членам спільноти! Ваші різноманітні погляди та досвід були життєво важливими для нашого спільного успіху.

  • Найкращі 5 комітерів: Особлива подяка brminnick, VladislavAntonyuk, jfversluis, pictos та cat0363. Ваша відданість та внесок були зразковими.

  • 4190 репозиторій залежать від нас: Понад 4190 репозиторіїв покладаються на CommunityToolkit.Maui, що є свідченням нашого впливу, який дедалі зростає.

  • 679 767 завантажень з NuGet: Неймовірна кількість завантажень цього року свідчить про широке розповсюдження та довіру до нашого інструментарію.

Важливі доповнення

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

image showing the feature list and components of .NET MAUI Community Toolkit v7.0.1

  • Media Element: Пориньте у світ мультимедіа з нашим новим елементом керування Media Element. Незалежно від того, чи ви транслюєте потокове відео з Інтернету, чи використовуєте вбудовані ресурси, чи отримуєте доступ до локальних файлів, цей елемент керування безперешкодно відтворює відео- та аудіоконтент у ваших додатках .NET MAUI.

.NET MAUI Toolkit media element on phone

  • Інтеграція з картами Windows: Наша інтеграція з картами дозволяє використовувати можливості карт .NET MAUI безпосередньо на платформі Windows, покращуючи сервіси на основі визначення місцеперебування у ваших додатках.

  • SpeechToText і розпізнавання мовлення: Розкрийте потенціал голосу за допомогою наших функцій SpeechToText і розпізнавання мовлення. Взаємодійте та керуйте своїми програмами за допомогою усної мови, відкриваючи новий вимір доступності та зручності. Дізнайтеся більше про це в цій статті в блозі.

Відео

 

  • FolderPicker та FileSaver: Виведіть керування файлами на новий рівень. FolderPicker дозволяє користувачам легко переміщатися і вибирати каталоги, а FileSaver надає свободу вибору теки призначення і дозволяє легко зберігати файли.

Відео

 

  • Розширення клавіатури: Отримайте контроль над екранною клавіатурою. Перевіряйте її видимість, приховуйте її або викликайте за бажанням, забезпечуючи більш плавну та інтуїтивно зрозумілу роботу з клавіатурою у ваших додатках .NET MAUI.

  • Badge API: Представляємо Badge API – найпростіше рішення для відображення кількості сповіщень на іконках ваших додатків. Тримайте користувачів в курсі подій та інформуйте їх лише одним переглядом.

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

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

Але це ще не все

Інструментарій .NET MAUI Community Toolkit виходить за рамки основного пакета NuGet, ми також пишаємося нашою документацією, розміщеною в нашому репозиторії Docs, і універсальним пакетом .NET MAUI Markup для розробників, які схильні до підходу, що не використовує XAML. Обидва ці  компоненти інструментарію отримують постійні оновлення, про що свідчать:

Репозитарій документів:

  • Комітів: 192

  • Дописувачі: 25

  • Топ-5 дописувачів: bijington, jfversluis, brminnick, Sergio0694, VladislavAntonyuk

Репозиторій розмітки MAUI:

  • Зафіксовано: 104

  • Дописувачі: 9

  • Топ-5 дописувачів: brminnick, Youssef1313, bijington, VladislavAntonyuk, JoonghyunCho

Окрім цього, інструментарій .NET MAUI Community Toolkit з гордістю святкує визначну подію – понад 1 мільйон завантажень, що свідчить про його надійність, міцність та довіру, яку він завоював у спільноті розробників.

nuget download trend

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




Posted on 25. February 2024

WinForms in a 64-Bit world – our strategy going forward

WinForms у 64-бітному світі – наша стратегія на майбутнє

Будучи частиною спільноти, яка процвітає завдяки інноваціям та зростанню, WinForms розробники часто розширюють межі для створення нових можливостей. Наші розробники також відповідають за підтримку критично важливого для бізнесу програмного забезпечення, яке часто створюється вже більше десяти років. Ми цінуємо вашу довіру і вашу пристрасть до створення чудових програмних рішень за допомогою наших інструментів. Як ви, можливо, знаєте, перехід з 32-бітної на 64-бітну версію Visual Studio 2022 призвів до певних складнощів. Ми усвідомлюємо, що ці зміни спричиняють певні перешкоди на шляху вашої розробки, і ми хочемо прояснити ці проблеми, вказавши на вже доступні обхідні шляхи та наші додаткові плани щодо їх вирішення.


Переходимо на 64-біт: Зміни на краще

 

Рішення перейти на 64-бітну платформу – це набагато більше, ніж просте оновлення. Це значне покращення, яке допомагає Visual Studio працювати краще у кількох аспектах. Однією з найбільших переваг є можливість використовувати більше пам’яті. У 32-бітній версії існували обмеження на обсяг пам’яті, який Visual Studio могла використовувати, що часто призводило до сповільнення роботи або навіть помилок при роботі над великими проектами. 64-розрядна версія усуває ці обмеження, дозволяючи Visual Studio працювати з великими проектами з більшою ефективністю.

Але справа не лише у доступі до більшого об’єму пам’яті. Перехід на 64-розрядність також дозволяє Visual Studio краще використовувати процесор вашого комп’ютера, зокрема, його декілька ядер. Оскільки 64-бітовий додаток може обробляти більше даних одночасно, він може використовувати більше ядер одночасно і ефективно, що призводить до швидшої роботи. Це особливо помітно під час створення вашого проекту. Якщо ваш проект великий, з великою кількістю файлів і коду, операція збірки може бути значно швидшою на 64-бітній системі. Це означає, що вам доведеться менше чекати на завершення збірки, що допоможе вам швидше виконати свою роботу. Але це не єдині переваги. Є й інші:

  • Сумісність з 64-бітними бібліотеками: Існує багато 64-бітних бібліотек та компонентів, які просто неможливо ефективно використовувати у 32-бітній версії Visual Studio. 64-розрядна версія дозволяє краще використовувати та інтегрувати ці ресурси.

  • Покращена безпека: 64-розрядні системи мають деякі вбудовані переваги в безпеці порівняно з 32-розрядними, зокрема функцію під назвою Randomization of Address Space Layout (ASLR), яка ускладнює зловмисному коду використання системи.

  • Націленість на майбутнє: З розвитком технологій все більше програм та операційних систем переходять на 64-бітну архітектуру. Переходячи на 64-бітну архітектуру зараз, Visual Studio слідує за цією хвилею, забезпечуючи сумісність з майбутніми технологічними досягненнями.

  • Більші набори даних: Завдяки 64-бітним обчисленням ви можете працювати зі значно більшими наборами даних, з якими раніше було неможливо впоратися через обмеження пам’яті. Це особливо корисно на етапі проектування в таких галузях з інтенсивним використанням даних, як машинне навчання, аналіз великих даних, а також для завдань, які передбачають обробку схем великих і складних баз даних, наприклад, для генерації коду.

Де використовується WinForms?

Ці переваги справедливі і для WinForms Designer. Дуже часто додатки WinForms відображають складні бізнес-кейси. Як наслідок, ці програми часто містять сотні форм та елементів управління, які самі по собі можуть стати дуже великими та складними. Все це призводить до великої кількості коду, який потрібно генерувати щоразу, коли форма редагується. Тому одним з найбільших бенефіціарів переходу на 64-бітну версію, безсумнівно, є WinForms Designer. Дизайнер використовує можливість доступу до більшого обсягу пам’яті в 64-бітній архітектурі, що значно підвищує його продуктивність і здатність обробляти складні завдання проектування.


Проблеми 32-бітних застарілих компонентів

При цьому ми повністю усвідомлюємо, що цей прогрес супроводжується певними проблемами, пов’язаними з компонентами, які прив’язані до 32-розрядної архітектури і використовуються в контексті дизайнера Windows Forms для проектів, орієнтованих на .NET Framework версій до 4.8.1.


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


Які у мене є варіанти?

У вас є кілька варіантів, кожен з яких має свої переваги:

  • Перехід на .NET 8+: Найбільш далекоглядним варіантом є перехід на .NET 8 або новішу версію. Середовище .NET 8+ – це майбутнє (і не тільки) розробки WinForms-додатків, воно забезпечує найнадійнішу підтримку, особливо коли мова йде про сторонні системи керування. З .NET 8+ ви не просто йдете в ногу з часом – ви випереджаєте його, гарантуючи, що ваші додатки будуть готові до всього, що принесе майбутнє.

  • Використовуйте AnyCPU: По-перше, на час проектування, переключіть все на збірку з ‘AnyCPU’. Опція компіляції ‘AnyCPU’ у Visual Studio пропонує універсальне рішення для вирішення проблеми 32-бітних компонентів у вашому WinForms проекті. Коли у вашому проекті встановлено опцію ‘AnyCPU’, Visual Studio скомпілює ваш додаток таким чином, щоб він міг працювати як на 32-бітних, так і на 64-бітних платформах. У контексті часу проектування така гнучкість означає, що ваш процес може працювати як 64-розрядний на 64-розрядній системі, дозволяючи вам повною мірою скористатися перевагами 64-розрядної Visual Studio, такими як покращене використання пам’яті та швидші операції. У багатьох випадках це працює досить добре для проектів, які вимагають 32-бітних компонентів для виконання. Коли йдеться про час виконання після завершення сеансу проектування, параметр проекту “Надавати перевагу 32-бітним” стає ключовим для сумісності зі старими 32-бітними компонентами або бібліотеками. Увімкнувши цей параметр, ви вказуєте Common Language Runtime (CLR) запускати ваш скомпільований додаток “AnyCPU” у 32-розрядному режимі навіть на 64-розрядній системі. Це забезпечує середовище, у якому ваші 32-розрядні компоненти функціонують належним чином, тим самим підтримуючи безперебійну роботу вашої програми. Хоча цей підхід накладає деякі 32-розрядні обмеження, такі як менший обсяг пам’яті, він пропонує ефективне рішення для балансування між потребою у 64-розрядних можливостях під час проектування та вимогами 32-розрядних компонентів під час виконання.

  • Модернізація 32-бітних компонентів: Якщо перший варіант неможливий через архітектуру 32-розрядного компонента, ви можете розглянути можливість міграції з 32-розрядних компонентів. Хоча це може вимагати початкових витрат часу і ресурсів, переваги, які ви отримаєте в довгостроковій перспективі, є значними. Перехід на 64-бітне середовище пропонує не лише кращу продуктивність, але й підвищену безпеку. Крім того, воно готує ваші програми до майбутніх оновлень і вдосконалень, забезпечуючи їхню довговічність.

Якщо всі ці варіанти не працюють у вашому конкретному випадку, як останній варіант є позапроцесорний конструктор WinForms Designer:

Адаптація до нового ландшафту: Позапроцесні конструктори

Для підтримки .NET Core 3.1 і вище ми створили позапроцесну версію дизайнера WinForms; окремий процес, який може виконувати завдання, які Visual Studio не може виконати як процес .NET Framework. Це, по суті, вимагало від нас створення абсолютно нової архітектури та моделі розширюваності для одночасної роботи з двома типами процесів. Оновлення до .NET пов’язане зі змінами як у середовищі виконання, так і в новому позапроцесному дизайнері. Хоча ми досягли паритету з найважливішими функціями часу проектування, є випадки, коли в новому технічному ландшафті немає сенсу застосовувати застарілі підходи.


Позапроцесний конструктор дозволяє нам обійти обмеження, які є проблематичними при внутрішньопроцесному дизайні, а саме проблеми з розміщенням компонентів, несумісних з цільовою структурою конструктора, наприклад, Visual Studio. Це досягається шляхом запуску нового процесу дизайнера, який потім працює в точній версії Target Framework, на яку був налаштований проект WinForms, що забезпечує більшу гнучкість в управлінні компонентами різних архітектур.

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


Однак це також означає, що всі окремі компоненти та їхні дизайнери елементів керування мають бути адаптовані для роботи в різних процесах. Якщо ви використовуєте власні бібліотеки елементів керування WinForms з індивідуальною підтримкою під час проектування за допомогою спеціальних дизайнерів елементів керування, які надають користувацьку серіалізацію CodeDOM, спеціалізовані редактори типів, персоналізовану візуалізацію прикрас або індивідуальні елементи дій дизайнера, вам потрібно перенести код вашого дизайнера, щоб використовувати WinForms Designer SDK. Ми зробили значний крок у цьому напрямку завдяки нашим елементам керування для .NET (Core, 5+). І що також важливо: більшість наших великих сторонніх постачальників бібліотек елементів керування також надають свої продукти для .NET версій 5, 6 і 7, а модернізовані версії для .NET 8 перебувають на стадії розробки.


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


Позапроцесний конструктор для додатків .NET Framework з 32-бітними компонентами

Ми побачили, що все більше людей потребують підтримки в розробці WinForms-додатків для 32-бітної платформи .NET Framework, оскільки ці додатки використовують частини, які працюють тільки в 32-бітному процесі. Тому ми адаптували підхід позапроцесного конструктора WinForms для .NET і представляємо 32-розрядний позапроцесний конструктор .NET Framework на його основі.


Позапроцесний конструктор створено для створення окремого 32-розрядного процесу, який може містити компоненти, необхідні для таких додатків. Таким чином, він обходить несумісність між 64-розрядним середовищем Visual Studio та 32-розрядними компонентами. Такий дизайн забезпечує більш плавну інтеграцію та сумісність, незважаючи на різницю в архітектурі систем.


Якщо ви спробуєте відкрити проект WinForms .NET Framework, який містить посилання на 32-розрядний компонент, Visual Studio автоматично відкриє діалогове вікно і запитає, чи хочете ви відкрити проект за допомогою позапроцесного конструктора 32-розрядного .NET Framework.

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


Ми розуміємо, що важливі застарілі проекти можуть покладатися на 32-розрядні елементи керування ActiveX та інші застарілі компоненти, які наразі несумісні з Visual Studio 2022, особливо для проектів, орієнтованих не на .NET (Core, 5+), а на .NET Framework до версії 4.8.1. У цих випадках позапроцесорні дизайнери можуть бути рішенням для багатьох випадків використання. Але зауважте, що позапроцесний конструктор WinForms для .NET (6+) також слід вважати кращим і найкращим варіантом – ви отримаєте найкраще з обох світів: 32-бітну сумісність під час проектування і виконання, а також найновішу, найсучаснішу і найпродуктивнішу версію .NET.


Важливо зазначити, що оновлений позапроцесний 32-розрядний дизайнер .NET Framework не досягне повного паритету зі старим вбудованим дизайнером .NET Framework через ті ж самі архітектурні відмінності, які згадувалися для позапроцесного дизайнера для .NET Core. Це також означає, що висококастомізовані дизайнери елементів керування не будуть сумісні з вбудованим дизайнером .NET Framework “з коробки”. Якщо ви використовуєте користувацькі бібліотеки елементів керування від сторонніх розробників, перевірте, чи є в них версії, які підтримують позапроцесний конструктор .NET Framework.


Підтримка застарілих компонентів: Наші зобов’язання та плани

Позапроцесорні дизайнери – це те, на що ми докладаємо найбільше зусиль у майбутньому. І ось план нашої дорожньої карти на цей рік:

  • Покращення позапроцесного дизайнера 32-Bit Framework: Цей конструктор буде вибором для підтримки проектів, які не можуть бути перенесені на .NET (Core, 5+), але залежать від застарілих 32-бітних компонентів. Цей дизайнер не матиме паритету функцій з дизайнером в процесі, але ми будемо додавати більше функцій, коли побачимо попит на них з боку клієнтів. Зверніть увагу, що 32-розрядний конструктор фреймворків вже знаходиться у попередньому перегляді і його можна активувати на сторінці Інструменти/Опції.


У Visual Studio 2022 версії 17.9 ми випустили функцію, яка допоможе вам легко вибрати, чи слід відкривати проект .NET Framework для класичного дизайнера Visual Studio в процесі або позапроцесного дизайнера. Відмінності у порівнянні з класичним in-process дизайнером WinForms будуть наступними:

  • Ви зможете відкривати і створювати форми та елементи управління користувача, орієнтовані на .NET Framework (до версії 4.8.1) і покладаються на 32-розрядні компоненти ActiveX або з інших причин, які змушують створювати 32-розрядну збірку в Конструкторі.

  • Якщо ви використовуєте спеціальні бібліотеки керування сторонніх розробників для проектів, які покладаються на застарілі 32-розрядні компоненти, ви не можете використовувати ті ж версії цих бібліотек, які сторонні розробники надають для класичного вбудованого дизайнера. Зверніться до постачальника бібліотеки керування, щоб дізнатися, чи є оновлена версія для позапроцесного дизайнера .NET Framework.

  • Дизайнер типізованих наборів даних і редактор запитів SQL Server в контексті розроблених наборів даних залишаться доступними лише для класичного дизайнера в процесі. Однак пізніше цього року ми представимо оновлені функції, які полегшать і зроблять можливим використання джерел даних на основі існуючих типізованих наборів даних, так що підтримка сценаріїв прив’язки даних на основі існуючих джерел даних буде продовжувати підтримуватися і надалі. Однак наразі ми не плануємо підтримувати класичні вікна джерел даних у позапроцесному дизайнері .NET Framework.

  • Джерела даних, засновані на класичних веб-сервісах SOAP, не підтримуються позапроцесним дизайнером ні для додатків .NET, ні для додатків .NET Framework.

  • Надання інфраструктури для Root Designers: Сторонні постачальники та автори бібліотек елементів керування покладаються на кореневі конструктори – наприклад, коли вони хочуть перенести свої дизайнери звітів з .NET Framework на .NET Core. Додавши підтримку кореневого дизайнера до позапроцесного дизайнера, ми дамо змогу авторам елементів керування модернізувати свої потужні дизайнери звітів та інші типи дизайнерів документів і перенести їх на .NET 6, 7 і 8+. Однак наразі ми не плануємо підтримувати власні кореневі дизайнери для позапроцесного дизайнера .NET Framework.

Рух вперед: Спільні зусилля

Перехід на 64-бітну систему – це важлива віха, яка вимагає нового підходу, інноваційних рішень і терпіння. Як згадувалося раніше, це не швидке виправлення помилок; скоріше, це перехід, яким ми повинні керувати разом як спільнота.

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


Насамкінець, ми розуміємо складнощі, з якими ви стикаєтесь, і хочемо запевнити вас, що ми робимо кроки у вирішенні цих проблем. Пам’ятайте, що зміни часто супроводжуються певним дискомфортом, але вони прокладають шлях до зростання та кращих результатів. Ми хочемо підкреслити важливість вашої активної участі в цьому перехідному періоді. Оскільки ми постійно прагнемо поліпшити і доопрацювати 64-розрядний дизайнер і нашу підтримку позапроцесного дизайнера, ваші відгуки та повідомлення про помилки є безцінними. Якщо ви зіткнулися з будь-якими специфічними проблемами під час використання WinForms, ми наполегливо рекомендуємо вам повідомляти про них безпосередньо в репозиторій WinForms на GitHub або через функцію зворотного зв’язку Visual Studio. Детальні, конкретні звіти про проблеми, особливо ті, що містять інформацію про середовище, кроки для відтворення та конкретні повідомлення про помилки, надзвичайно допомагають нам у виявленні та вирішенні проблем більш ефективно та швидко. Ваша участь у цьому процесі має вирішальне значення для успішної розробки більш надійної та ефективної Visual Studio, оскільки технологія, на якій базуються всі застарілі 32-розрядні компоненти, у багатьох випадках налічує 20 років і більше.


Заключні думки

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


Дякуємо вам за вашу підтримку і прихильність, оскільки ми рухаємося вперед до більш потужної і універсальної екосистеми WinForms, і як завжди…


…щасливого кодування!

 

Source



Posted on 15. February 2024

Our Vision for .NET 9

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

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


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


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


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

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


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


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


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


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

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


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


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


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

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


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


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


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


.NET 9 Беклог

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


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


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

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


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

 

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



Posted on 10. December 2023

.NET 8 Networking Improvements

Покращення роботи з мережею в .NET 8

Вже стало традицією публікувати в блозі повідомлення про нові цікаві зміни в мережевому просторі з новим випуском .NET . Цього року ми хотіли б запровадити зміни в просторі HTTP , нові додані метрики, нові API HttpClientFactory, тощо.


HTTP

Метрики

.NET 8 додає вбудовані HTTP-метрики як до ASP.NET Core, так і до HttpClient, за допомогою System.Diagnostics.Metrics API, який був представлений у .NET 6. І API-інтерфейси Metrics, і семантика нових вбудованих показників були розроблені у тісній співпраці з OpenTelemetry, переконуючись, що нові показники відповідають стандарту та добре працюють із такими популярними інструментами, як Prometheus і Grafana. .

API System.Diagnostics.Metrics представляє багато нових функцій, яких не було в EventCounters. Ці функції широко використовуються новими вбудованими метриками, що призводить до ширшої функціональності, досягнутої простішим і елегантнішим набором інструментів. Наведу кілька прикладів:

Гістограми дозволяють нам повідомляти про тривалості, напр. тривалість запиту ( http.client.request.duration) або тривалість з’єднання (http.client.connection.duration). Це нові показники без відповідників EventCounter.

Багатовимірність дозволяє нам додавати теги (атрибути або мітки) до вимірювань, що означає, що ми можемо повідомляти таку інформацію, як server.address (ідентифікує джерело URI) або error.type (описує причину помилки, якщо запит не вдається) разом із вимірюваннями. Багатовимірність також забезпечує спрощення: для звітування про кількість відкритих HTTP-з’єднань SocketsHttpHandler використовує 3 EventCounters: http11-connections-current-total, http20-connections-current-totalіhttp30-connections-current-total , тоді як еквівалент цих лічильників Metrics є одним інструментом, http.client.open_connections, де версія HTTP повідомляється за допомогою тегу network.protocol.version.

Щоб допомогти використати випадки, коли вбудованих тегів недостатньо для класифікації вихідних HTTP-запитів, метрика http.client.request.duration підтримує впровадження тегів, визначених користувачем. Це називається збагаченням.

Інтеграція IMeterFactory дозволяє ізолювати екземпляри Meter, які використовуються для випромінювання метрик HTTP, що полегшує написання тестів, які перевіряють вбудовані вимірювання, і дозволяє паралельне виконання таких тестів.

– Хоча це не стосується вбудованих мережевих метрик, варто зазначити, що API колекції System.Diagnostics.Metrics також є більш досконалими: вони суворо типізовані та більш продуктивні та відкривають кільком слухачам одночасно доступ до неагрегованих вимірювань.

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

З іншого боку, слід зазначити, що лише компоненти System.Net.Http та System.Net.NameResolution інструментуються за допомогою System.Diagnostics.Metrics у .NET 8, а це означає, що вам все одно потрібно використовувати EventCounters для отримання лічильників із нижчих рівнів стеку, таких як System.Net.Sockets. Хоча всі вбудовані лічильники подій, які існували в попередніх версіях, все ще підтримуються, команда .NET не очікує значних нових інвестицій у лічильники подій, і нові вбудовані інструменти будуть додані, використовуючи System.Diagnostics.Metrics, в майбутніх версіях.

Щоб отримати додаткові відомості про використання вбудованих метрик HTTP, прочитайте наш підручник щодо мережевих метрик у .NET . Він містить приклади збирання та звітування за допомогою Prometheus і Grafana, а також демонструє, як збагачувати та тестувати вбудовані HTTP-метрики. Щоб отримати вичерпний список вбудованих інструментів, перегляньте документацію для метрик System.Net . Якщо вас більше цікавить серверна сторона, будь ласка, прочитайте документацію про показники ASP.NET Core.

Розширена телеметрія

Окрім нових показників, наявні телеметричні події EventSource, представлені в .NET 5, були доповнені додатковою інформацією про HTTP-з’єднання ( dotnet/runtime#88853 ):

Тепер, коли встановлюється нове з’єднання, подія логує connectionId разом із схемою, портом та IP-адресою однорангового пристрою. Це дає змогу співвідносити запити та відповіді зі з’єднаннями через подію RequestHeadersStart, яка виникає, коли запит пов’язується з об’єднаним з’єднанням і починає оброблятися, яка також реєструє пов’язані connectionId. Це особливо цінно в діагностичних сценаріях, коли користувачі хочуть бачити IP-адреси серверів, які обслуговують їхні HTTP-запити, що було основною мотивацією додавання ( dotnet/runtime#63159 ).

 

Події можна використовувати багатьма способами, див. Мережева телеметрія в .NET – Події . Але для покращеного журналювання під час процесу EventListener можна використовувати спеціальний параметр, щоб співвіднести пару запит/відповідь із даними підключення: