Posted on 19. October 2023

Windows launching Arm Advisory Service for developers

 

Windows запускає службу підтримки розробників Arm Advisory Service.

Багато розробників вважають, що створювати програми для Windows on Arm важко, але розробляти для Arm легше, ніж ви думаєте, і Microsoft тут, щоб допомогти! Мені приємно оголосити про нову консультативну службу App Assure Arm, яка допоможе розробникам створювати програми, оптимізовані для Arm. Ця послуга є доповненням до нашої обіцянки: ваші програми працюватимуть на Windows on Arm, і якщо у вас виникнуть проблеми, Microsoft допоможе їх усунути. Більшість додатків просто працюють в режимі емуляції, і розробники можуть перенести свої додатки на нативний запуск із мінімальними зусиллями. Все більше виробників пристроїв створюють пристрої Arm з певної причини – пристрої легкі, мають блискавичне підключення, пропонують подовжений термін служби батареї та мають розширені можливості камери та аудіо на додаток до багатьох інших переваг. Ці переваги можуть сприяти зростанню залучення клієнтів до пристроїв Arm, що спонукає більше постачальників програмного забезпечення до розробки оптимізованих для Arm версій своїх програм, як показано в розділі нижче. У двох словах, екосистема Arm швидко розширюється.


Згідно з даними Counterpoint , до 2027 року частка ринку Arm збільшиться майже вдвічі з 14% до 25%. Це означає, що сумісність програм для Windows on Arm є важливою для подальшої життєздатності ваших програм! Хоча ми тільки сьогодні офіційно оголошуємо про Arm Advisory Service, ми вже більше ніж три роки допомагаємо розробникам створювати програми, оптимізовані для Arm. Ми співпрацюємо з розробниками, щоб ділитися порадами та найкращими практиками, і ми робимо значні інвестиції та розширюємо підтримку розробників. Наприклад, наша консультаційна служба Arm уже допомогла незалежним постачальникам програмного забезпечення у сфері запобігання втраті даних (DLP) і наборів продуктів для захисту від зловмисного програмного забезпечення на Arm, надаючи зразки коду, огляди коду, обмінюючись найкращими методами розробки та допомога з налагодження. Ця допомога в розробці Arm є ключовою для того, щоб незалежні розробники програмного забезпечення могли оптимізувати свої програми для Arm.

Особливості програми консультаційних послуг

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

- Технічний воркшоп для передових практик розробки, інструкцій та питань впровадження

- Пропозиції щодо функцій платформи для покращення роботи програми Arm

- Зразки коду та огляди для розробки Arm

- Допомога у розв’язанні проблем, які виникають під час портування або створення програм Arm

- Шлях ескалації до інженерів Microsoft для допомоги в розробці програмного забезпечення та надання відгуків про продукт


Щоб розпочати роботу з Arm Advisory Service, заповніть цю форму , і наша команда App Assure зв’яжеться з вами. Якщо у вас виникли проблеми, зв’яжіться з нами за адресою ACHelp@Microsoft.com.


Відгуки ISV

Консультаційна служба Arm вже допомогла незалежним постачальникам програмного забезпечення розробити нативні програми Arm. Ознайомтеся з цими нещодавніми відгуками про те, як App Assure забезпечив успішну розробку Arm для Zscaler, великої компанії з хмарної безпеки, і Absolute, провідної компанії з кібербезпеки.

Логотип Zscaler

«Перенесення клієнтського конектора Zscaler на Arm стало чудовим досвідом завдяки незрівнянній підтримці команди Microsoft App Assure. Команда App Assure залучала наших звичайних клієнтів, проводила періодичні зустрічі для відстеження, допомагала впоратися зі складними технічними проблемами, надавала глибокі рішення на рівні ОС тощо. Вони також поділилися спеціальним обладнанням ARM, яке допомогло в розробці та тестуванні. Нарешті, вони доклали особливих зусиль, щоб допомогти нашим стороннім постачальникам бібліотек також перенести їхнє програмне забезпечення. Зараз у нас понад 100 клієнтів, які використовують наш клієнт ARM. Дякуємо команді App Assure і Microsoft!»

Абсолютний логотип

«Запатентована технологія стійкості Absolute вбудована в понад 600 мільйонів пристроїв по всьому світу та забезпечує можливості самовідновлення та стійкості як для обчислювальних платформ Intel, так і для Arm. Коли провідний виробник ПК захотів дізнатися більше про те, як Absolute Secure Endpoint забезпечує стійкість на пристроях на базі Arm на додаток до мікросхем Intel, команда App Assure сприяла змістовній дискусії з технічними та маркетинговими ресурсами. Свідченням нашого партнерства з Microsoft є те, що тестування та сертифікація проходили неймовірно швидко, і ми завершили проєкт вчасно та в рамках бюджету. Ми з нетерпінням чекаємо співпраці з командою App Assure для майбутніх ринкових можливостей».


Окрім Zscaler і Absolute, команда App Assure допомогла іншим постачальникам програмного забезпечення розробити програми, оптимізовані для Arm:

14 логотипів

 

Mike Adams, Corporate Vice President, Customer Experience Engineering




Posted on 18. October 2023

Announcing .NET MAUI in .NET 8 Release Candidate 2: More Quality

Анонс .NET MAUI у .NET 8 Release Candidate 2: Більше Якості


Сьогодні ми робимо ще один крок на зустріч до загального доступу до .NET 8 (GA), надаючи .NET MAUI у версії 2 (RC2) .NET 8. Як і RC1, на цей випуск поширюється ліцензія на запуск, тому ви можете отримати підтримку під час використання його у своїх робочих програмах. У цьому релізі ми зосередилися на проблемах, які регресували під час попереднього перегляду, і відновили деяку продуктивність, яку було втрачено, коли ми покращили надійність гарячого перезавантаження, візуального менеджера стану, прив’язки та тем додатків.

Покращення якості

 

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


Основні моменти з цього релізу:


Покращення продуктивності: було зроблено кілька покращень продуктивності, зокрема покращено продуктивність ActivityExtensions.GetWindowFrame на Android і продуктивність «Setter Specificity». Ці оптимізації сприяють плавній роботі програми. (#17241 , #17364 , #17230 , #17505 , #17545).

 

 

Виправлення інтерфейсу користувача та елементів керування: було внесено кілька виправлень і оновлень до елементів керування та елементів інтерфейсу користувача, зокрема виправлення, пов’язані з CollectionView, видимістю TabBar, межами RoundRectangle і вирівнюванням тексту Android. Завдяки цьому інтерфейс вашого додатка є більш узгодженим і візуально точнішим на різних платформах. (#16870 , #17240 , #17261 , #17353 , #17430 , #17594, #17567).

 

Спеціалізовані виправлення для платформ: було внесено кілька специфічних  виправлень для платформ, зокрема функцію перетягування, зовнішній вигляд панелі вкладок і певну поведінку платформи, що забезпечує узгоджену взаємодію користувачів на різних платформах. (#15748 , #16561 , #17495 , #17041 , #17358).


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

Додаткова інформація:


- Примітки до релізу .NET MAUI

- .NET для Android

 

- .NET для iOS і Mac

 

Бонус: Реліз Сервісу .NET 7

Сьогодні ми також надіслали 8 реліз  сервісу .NET MAUI (версія 7.0.96) для .NET 7, включаючи вибрані високопріоритетні виправлення макета, витоків пам’яті, CollectionView, безпечної зони тощо. Ви можете скористатися цією версією служби, інсталювавши .NET 8 RC2 одним із наведених нижче методів і продовживши створювати свої програми для .NET 7.


Крім того, ви можете отримати 7.0.96, оновившись до Visual Studio 17.7.5.

Бонус 2: Xcode 15 та Android API 34

 

Тепер розробники Xamarin можуть використовувати Xcode 15 для націлювання на останні версії (наприклад, iOS 17, iPadOS 17) і націлювати Android API 34 , щоб відповідати політикам магазину. Для цього встановіть Visual Studio 17.8 Preview 3 або останню стабільну версію Visual Studio для Mac і налаштуйте середовище, як зазвичай. Це не надає нових API для платформи, але дозволяє продовжувати створення наявних проєктів, поки ви завершите оновлення до .NET 8 і .NET MAUI, незалежно від дати завершення підтримки Xamarin наступного року .

Як оновити

На всіх платформах ви можете розробляти з .NET MAUI за допомогою Visual Studio Code. Установіть розширення .NET MAUI і повідомте нам, як ми можемо покращити це прев’ю для вас у майбутньому.


Завантажте програму встановлення .NET 8 RC2 , а потім інсталюйте .NET MAUI з командного рядка:

 

dotnet workload install maui

 

Після припинення використання Visual Studio для Mac наступного року ви зможете продовжувати розробку за допомогою Visual Studio для Mac після ввімкнення функції попереднього перегляду для .NET 8 у параметрах.

 

Зворотний зв’язок

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


Дякуємо всім 23 учасникам (і ботам), які допомогли створити цей випуск!


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


У Windows оновіть або встановіть Visual Studio 2022 17.8 preview 3, щоб отримати .NET 8 RC2 із .NET MAUI (і 7.0.96).

 

Source




Posted on 10. October 2023

C# Dev Kit – Now Generally Available

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

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

C# Dev Kit

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

 

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



Posted on 15. July 2023

Анонс .NET 8 Preview 6

 

 

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

 

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


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


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


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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

 

JsonStringEnumConverter

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

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

 

 

JsonConverter.Type

 

 

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

 

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

 

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

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

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

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

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

 

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

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

 

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


Метрики API MetricCollector

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

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

 

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

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

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

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


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


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

 

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


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


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

 

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

 

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

 

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

 

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

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


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


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

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

 

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


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

 

 

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

 

 

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

 

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

 

GeneratedComClassAttribute

 

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

 

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

 

Взаємодія з LibraryImportAttribute


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

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

 

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

Обмеження

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

 

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

 

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

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

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


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

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


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


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


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

 

Режим HybridGlobalization на WASM

 

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

 

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

 

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

у Blazor WebAssembly або

у браузері WASM.

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

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

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

Обмеження

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


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

 

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

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

 

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

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

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

.NET iOS app( )dotnet new ios

.NET MAUI iOS app( )dotnet new maui

 

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Резюме

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

 

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

 

Source




Posted on 9. July 2023

У .NET Community Toolkit 8.2.1 з’явилися покращені генератори вихідного коду та засоби виправлення коду!

 

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


.NET Community Toolkit 8.2.1

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

Що входить до складу .NET Community Toolkit?

.NET Community Toolkit містить такі бібліотеки:

CommunityToolkit.Common

CommunityToolkit.Mvvm(він же «Microsoft MVVM Toolkit»)

CommunityToolkit.Diagnostics

CommunityToolkit.HighPerformance

Щоб дізнатися більше про історію .NET Community Toolkit, ось посилання на нашу попередню публікацію оголошення про 8.0.0 .

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

Новий аналізатор і коректор коду для[RelayCommand] 

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

Щоб допомогти з цим, версія 8.2.1 MVVM Toolkit постачається з абсолютно новим аналізатором, який випромінює діагностику для методів async void , позначених [RelayCommand]. А щоб зробити роботу ще простішою, є також новий засіб виправлення коду, який автоматично перероблятиме код за вас — просто клацніть піктограму лампочки, і дозвольте Roslyn зробити роботу за вас!

Виправлення коду аналізатора MVVM Toolkit

 

Тут ви можете побачити нову згенеровану діагностику, яка відображається для методу async void, пов’язаного з командою, і відповідного інтерфейсу коректора коду у Visual Studio з попереднім переглядом змін. Він також автоматично додасть необхідний оператор using у верхній частині вашого файлу, якщо Task ще немає в області видимості. І так само, як і інші засоби виправлення коду в MVVM Toolkit, ви також можете легко застосувати його до всіх місць у всьому вашому проєкті чи рішенні одним клацанням миші!

Інші зміни та вдосконалення

Виправлено аварійну ситуацію при індексації розрізаного екземпляра Memory2D (#675): у деяких випадках могло бути викликано порушення доступу під час індексування елементів після нарізання екземпляра Memory2D. Тепер це виправлено, дякуємо mahalex за повідомлення про це!

– Виправлено атрибути пересилання з від’ємними значеннями переліку (#681): використання елементів переліку з від’ємними значеннями більше не спричиняє проблеми з генераторами MVVM Toolkit для згенерованих спостережуваних властивостей. Дякуємо n-coelho-cerinnov за повідомлення про це!

Виправлено збій генератора під час пересилання недійсних атрибутів (#683): спроба переслати атрибути, на які є неправильні посилання, тепер завершуватиметься помилкою та створюватиме зрозуміле повідомлення про помилку.

Виправлення генератора  ObservableValidator для виявлення успадкованих властивостей (#616): генератор для перевірки властивостей більше не буде випадково ігнорувати властивості базових типів для цільової моделі перегляду. Дякуємо dgellow за повідомлення про це!

Додано попередження під час використання packages.config для MVVM Toolkit (#695): генератори набору інструментів MVVM працюють лише під час використання (це відоме обмеження SDK, і воно є задумом), але раніше не було чітких вказівок на те, чому генератори не працювали для користувачів, які намагаються використовувати їх із проекту за допомогою packages.config. MVVM Toolkit тепер постачається з покращеною діагностикою, яка створить корисне попереджувальне повідомлення в цьому випадку. Дякуємо, smaugbend , що повідомили про це!

Частіше перевіряйте скасування в генераторах (#703): це має призвести до невеликих покращень у чутливості IDE під час використання MVVM Toolkit.

 

Видалення непотрібного тимчасового розподілу масиву (#719): ще одна невелика оптимізація пам’яті для генераторів джерел MVVM Toolkit.

Обробка поля [ObservableProperty] з ідентифікаторами ключових слів (#710): генератор більше не створюватиме недійсний код у випадку, якщо поля анотовані [ObservableProperty] використовують ідентифікатори ключових слів, які були екрановані у джерелі (наприклад, @event). Дякуємо Get0457 за повідомлення про це!

 

Примітка: існує відома проблема з джерельними генераторами в старіших версіях Roslyn, через яку IntelliSense іноді може не працювати належним чином для згенерованих учасників (див. #493 і пов’язану проблему відстеження Roslyn). Це нарешті виправлено у VS 2022 17.7, який зараз знаходиться в прев’ю. Якщо ви бачите будь-які проблеми під час використання MVVM Toolkit, обов’язково спробуйте останню версію VS 17.7 Preview!

Інші зміни

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

Почніть сьогодні!

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

 

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

Source




Posted on 7. May 2023

Анонсуємо нову версію .NET Upgrade Assistant з підтримкою .NET MAUI та Azure Functions!

та

 

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