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

 

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

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

 

  • Підтримка .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 – додано покращення щодо того, як проекти оновлюються за лаштунками.

 


Детальніше про оновлення до .NET 6, 7, 8

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


Ось як працює оновлення пакунків:

 

  • Для стандартних пакетів середовища виконання .NET або пакетів ASP.NET Core буде встановлено останню версію відповідного цільового фреймворку 6, 7 або 8. Наприклад, якщо ви оновлюєте свій додаток до .NET 6, ви отримаєте відповідну версію пакета для .NET 6, а якщо ви оновлюєте його до .NET 8, ваші пакети будуть оновлені до останніх передрелізних версій.
  • Для всіх інших пакунків інструмент перевіряє, чи пакунок вже підтримує цільовий фреймворк, у такому випадку пакунок залишається незмінним. Якщо ні, інструмент перевірить, чи остання версія пакунка підтримує цільовий фреймворк, до якого оновлюється програма. Якщо навіть остання версія пакунка не підтримує цільовий фреймворк, цей пакунок буде вилучено.
Ще одна нова функція – підтримка оновлень Preview: тепер ви можете оновити стару версію Preview до найновішої.

 


Оновлення з Xamarin.Forms на .NET MAUI

Тепер ви можете оновити ваші існуючі додатки Xamarin.Forms до наступника Xamarin – .NET MAUI.

У порівнянні з Xamarin.Forms, .NET MAUI має багато переваг та покращень, таких як:

 

  • єдиний проект для спрощення управління активами, управління NuGet та використання багатоцільового таргетингу.
  • багатовіконна підтримка сценаріїв для настільних комп’ютерів та планшетів
  • перебудований макет для покращення зручності супроводу, продуктивності та виправлення багатьох особливостей, присутніх у Xamarin.Forms.
  • Конструктор додатків для стандартизації завантаження додатків за загальним шаблоном .NET
  • Відокремлення платформи від крос-платформних елементів керування
  • Шаблон багаторівневого рендерингу над новими обробниками
  • Рефакторинг реалізацій Shell

 

та багато іншого. Ви можете прочитати документацію по .NET MAUI для більш детальної інформації.

Щоб оновити ваш додаток Xamarin.Forms до .NET MAUI:

 

  • У Visual Studio в Solution Explorer клацніть правою кнопкою миші на одному з ваших проектів і виберіть Upgrade. Вам потрібно встановити розширення Upgrade Assistant Visual Studio, щоб побачити опцію Upgrade. Ви можете почати з будь-якого проекту у вашому рішенні; вам потрібно буде оновити всі проекти, щоб ваш додаток зібрався.

 

 


 

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

 

  • Виберіть In place, якщо ви хочете оновити ваш оригінальний проект, або Side-by-side, якщо ви хочете створити новий проект MAUI поруч з вашим оригінальним проектом і залишити оригінальний проект без змін.
  • Дотримуйтесь кроків оновлення. Якщо у вас немає причин для поступового оновлення деяких частин вашого проекту, залиште всі позначки, які пропонує інструмент, і виконайте оновлення.
  • Повторіть це для кожного проекту вашого рішення.
  • Після завершення оновлення ви побачите, що інструмент змінив файли проекту, оновив посилання та вніс інші необхідні зміни. Створіть і запустіть ваші програми. Якщо виникнуть будь-які інші помилки, вам доведеться виправити їх вручну.
Примітка: для перетворень файлів .xaml Помічник оновлення включає базові заміни просторів імен. Для більш складних перетворень .xaml-файлів потрібна Visual Studio 17.6.

 

Оновлення для Azure Functions

Azure Functions – це безсерверна обчислювальна платформа, яка дає змогу запускати код без резервування або керування інфраструктурою. Існує чотири основні версії Azure Functions: 1.x, 2.x, 3.x і 4.x. Кожна версія має свій набір функцій і можливостей.

 

  • Версія 1.x – це найстаріша версія Azure Functions. Вона більше не підтримується і не повинна використовуватися для нових розробок.
  • Версія 2.x була випущена у 2017 році. Це значне оновлення порівняно з версією 1.x, яке включає низку нових функцій, зокрема підтримку декількох мов, покращену продуктивність і гнучкішу модель розгортання.
  • Версія 3.x була випущена в 2018 році. Це незначне оновлення порівняно з версією 2.x, яке включає кілька нових функцій, зокрема підтримку Azure Durable Functions і поліпшену інтеграцію з Azure Event Grid.
  • Версія 4.x була випущена в 2020 році. Це значне оновлення порівняно з версією 3.x, яке включає низку нових функцій, зокрема підтримку .NET 6, покращену продуктивність і більш безпечну архітектуру.

 

Також різні версії функцій Azure підтримуються в різних версіях .NET. У наступній таблиці наведено основні відмінності між різними версіями Azure Functions:

Під час оновлення проекту Azure Functions до останньої версії .NET інструмент автоматично оновить версію Azure Functions до ізольованої версії , оскільки це найкраща та рекомендована версія.

Ви можете оновити проект Azure Functions так само, як і будь-який інший проект, клацнувши правою кнопкою миші на проекті в Провіднику рішень, вибравши опцію Upgrade й дотримуючись вказівок інструмента.


Окрім оновлення файлу проекту до останньої версії .NET і версії Azure Functions, тіло функцій також оновлюється, щоб використовувати нові API.

Ви можете прочитати більше про функції Azure в документації.


Ідемо далі

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


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


Дізнайтеся, як оновити версію

У автора є багато матеріалів, які допоможуть вам у процесі оновлення:

 

 


Feedback!

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


Ви також можете надсилати проблеми або запити щодо можливостей Visual Studio, вибравши Довідка | Надіслати відгук. У темі листа обов’язково зазначте “Upgrade Assistant vsix”. 



 



Posted on 30. April 2023

Анонсуємо .NET Community Toolkit 8.2! Покращена швидкість роботи генераторів, засоби для усунення помилок у коді, збільшення продуктивності та багато іншого!

 

 

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

.NET Community Toolkit 8.1.0 Preview 1

Що входить до інструментарію .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, вибрати виправлення коду й автоматично застосувати всі необхідні зміни, щоб повернути ваш код до правильного вигляду! Вони також підтримують групові виправлення, тому ви можете виправити всі помилки одним клацанням! ✨

MVVM Toolkit analyzer code fix

Тут ви можете побачити новий інтерфейс виправлення коду у 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.DangerousGetArray() (#616): цей новий API дозволяє легко взаємодіяти між ArrayPoolBufferWriter та старими API, які вимагають масив T[] як параметр (на відміну від Span/Memory).

  • Вилучено 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. Всі ваші відгуки дуже допомагають формувати напрямок розвитку цих бібліотек, тому обов’язково діліться ними!

 

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



Posted on 20. February 2023

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

Оновлення .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.



Незабаром: 

Міграція з Xamarin на .NET MAUI

Міграція з UWP на WinUI

Міграція WCF на WCF Core


Ці типи міграції знаходяться в розробці, і ви вже можете оновити ці проекти, але у команди ще немає виправлень коду для цих проектів. Якщо вам потрібно перенести ці типи проектів сьогодні, рекомендовано скористатися наявним інструментом командного рядка Upgrade Assistant, який вже має виправлення коду. Розширення Visual Studio також незабаром отримає їх.


Різні типи оновлень

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

In-place. У цьому випадку ваш оригінальний проект буде оновлений одразу. Якщо ви використовуєте контроль вихідних текстів і віддаєте перевагу самостійному управлінню копіями, наприклад, за допомогою гілок, цей варіант для вас.

Side-by-side. За допомогою цієї опції ваш оригінальний проект не буде змінено, а до рішення буде додано його копію, яка міститиме оновлений код. Цей тип може бути зручним, якщо ваш додаток має багато залежностей, які можуть бути порушені після оновлення. Таким чином ви можете відстежувати прогрес і не турбуватися про те, що додаток не збирається.

Side-by-side incremental. Це ідеальний вибір для веб-додатків. Оновлення з ASP.NET на ASP.NET Core вимагає багато роботи, а іноді і ручного рефакторингу (тому що ці дві технології дуже відрізняються). Бібліотеки класів часто використовуються разом з веб-додатками, тому ми надаємо такий тип оновлення і для бібліотек класів. Інкрементне оновлення розмістить проект .NET 6/7 поруч з вашим існуючим проектом .NET Framework і спрямує туди кінцеві точки, які реалізовані в проекті .NET 6/7, в той час як всі інші виклики будуть надсилатися до додатку .NET Framework. Таким чином, ви можете поєднати оновлення з розробкою нових функцій і перенести елементи на .NET 6/7 один за одним, не порушуючи роботу вашого додатку. Цей підхід був спочатку реалізований в інструменті Microsoft Project Migrations, ви можете розглядати Upgrade Assistant у Visual Studio як нову покращену і розширену версію Microsoft Project Migrations. Оновлення з .NET Core або .NET 5 до .NET 6/7 набагато простіше, ніж з .NET Framework, тому для таких випадків рекомендується використовувати опцію In-place.

 

У таблиці нижче ви можете знайти статус усіх типів оновлень за типами проектів.


In-place

Side-by-side

Side-by-side incremental

ASP.NET from .NET Framework

N/A

N/A

supported

ASP.NET from .NET Core, .NET5+

supported

N/A

N/A

WinForms from .NET Framework

supported

supported

N/A

WinForms from .NET Core, .NET5+

supported

N/A

N/A

WPF from .NET Framework

supported

supported

N/A

WPF from .NET Core, .NET5+

supported

N/A

N/A

Class Library from .NET Framework

supported

supported

supported

Class Library from .NET Core, .NET5+

supported

N/A

N/A

Console from .NET Framework

supported

supported

N/A

Console from .NET Core, .NET5+

supported

N/A

N/A

Xamarin to MAUI

in development

in development

N/A

MAUI from older versions

in development

N/A

N/A

UWP to WinUI

in development

in development

N/A

WinUI from older versions

in development

N/A

N/A

Azure Functions

in development

N/A

N/A

WCF to WCF Core

in development

N/A

N/A


Покрокове оновлення

1. Встановіть розширення Upgrade Assistant Visual Studio.

2. У Visual Studio в Solution Explorer натисніть правою кнопкою миші на проекті, який ви хочете оновити, і виберіть Upgrade.

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



Posted on 23. January 2023

Анонс .NET Community Toolkit 8.1! Покращені, швидші генератори вихідного коду MVVM, підтримка .NET 7 та багато іншого!



Анонс .NET Community Toolkit 8.1! Покращені, швидші генератори вихідного коду MVVM, підтримка .NET 7 та багато іншого!

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

 

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

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

Ці бібліотеки також широко використовуються у деяких програмах для роботи з поштою, які входять до складу Windows, зокрема у Microsoft Store та програмі “Фотографії”! 

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

 

Нижче наведено перелік основних змін, які включено до нового випуску 8.1 інструментарію .NET Community Toolkit.

Користувацькі атрибути для [ObservableProperty] (Властивість, що спостерігається) 

Як вже згадувалося у блозі з анонсом 8.1.0 Preview 1, однією з найбільш запитуваних функцій (див. #208, #217, #228) для генератора вихідного коду MVVM Toolkit була підтримка використання користувацьких атрибутів для [ObservableProperty]. Було запропоновано декілька проєктів для підтримки цієї можливості, і зрештою було вирішено використати наявну властивість: синтаксис у C#, який дозволяє розробникам позначати атрибути для поширення їх на згенеровані властивості. Це дає кілька переваг:

1. Він використовує вбудований синтаксис C#, що робить властивість “рідною” і не потребує додаткових атрибутів

2. Це розв’язує проблему анотування атрибутів, які можуть бути спрямовані лише на властивості, а не на поля

 

Тобто, у MVVM Toolkit 8.1 тепер підтримується наступний сценарій:

Це призведе до створення наступної властивості за замовчуванням:

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

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

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

Аналізатори MVVM Toolkit 

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

Перший аналізатор розглядає поширену помилку при використанні атрибута [ObservableProperty]. Розглянемо такий приклад:

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

Другий новий аналізатор має на меті допомогти зменшити розмір двійкових файлів у додатках, що використовують MVVM Toolkit. Як вже згадувалося в анонсі 8.0.0, MVVM Toolkit включає декілька атрибутів (таких як [ObservableObject]), які дозволяють генераторам вставляти весь код, необхідний для реалізації інтерфейсів INotifyPropertyChanged та INotifyPropertyChanging (опціонально з додатковими допоміжними засобами) у вже наявні класи. Це особливо корисно у випадках, коли клас вже успадковується від іншого типу, ніж ObservableObject: ви можете використовувати атрибут і мати доступ до тих самих допоміжних функцій, не переробляючи логіку самостійно.

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

Тут MyViewModel не успадковує від жодного типу, тому їй краще успадкувати від ObservableObject, а не використовувати атрибут [ObservableObject], щоб отримати вигоду від покращення бінарного розміру. Новий аналізатор позначатиме всі сценарії, подібні до цього, пропонуючи використовувати успадкування. Це особливо допоможе новачкам, які можуть не розуміти нюансів двох різних підходів і не знати, як зробити вибір. У таких випадках аналізатор тепер буде поруч, щоб допомогти.

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

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

Ось лише деякі з покращень у цьому напрямку:

1. Додано багатоцільове орієнтування для Roslyn 4.3 (#428, #462): генератори вихідних кодів MVVM Toolkit тепер використовуватимуть орієнтир на Roslyn 4.3, якщо він підтримується, щоб вони могли підключатися до деяких оптимізованих API, якщо хост це підтримує. Ця функція автоматично вмикається при зверненні до MVVM Toolkit.

 

2. Використання ForAttributeWithMetadataName (#436): було переключено генератори на новий високорівневий API Roslyn для зіставлення атрибутів, що значно покращує продуктивність генераторів, які спрацьовують за певними атрибутами. Наприклад, [ObservableProperty] тепер використовує цю можливість.

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

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

5. Більше оптимізацій продуктивності (#447, #460, #469, #487, #489): було переглянуто всі інкрементальні моделі та інкрементальні конвеєри, що значно покращило продуктивність та зменшило виділення пам’яті.

Розширення месенджерів IObservable 

 

Ще однією запитуваною функцією, особливо розробниками, які інтенсивно використовують API у стилі Reactive у своїх додатках, була можливість об’єднати функціональність API месенджерів у MVVM Toolkit. Тепер це підтримується завдяки новим розширенням IObservable для інтерфейсу IMessenger. Їх можна використовувати наступним чином:

 

… Ось і все! Це розширення створить об’єкт IObservable, який можна використовувати для підписки на повідомлення і динамічної реакції на них. Також підтримується вказівка різних токенів за допомогою окремих перевантажень. Ось ще один приклад, що демонструє наскрізне використання нового API:

Підтримка .NET 7 та C# 11 

Цей новий випуск .NET Community Toolkit також додає .NET 7 TFM до пакета HighPerformance і містить кілька змін, що дозволяють скористатися новими можливостями мови C# 11, зокрема, посиланнями на поля (ref fields).

Наступні типи більше не знаходяться у попередньому перегляді й були оновлені для використання нових правил безпеки ref-полів:

Приклад, де вони можуть бути використані, наведено нижче:

Тобто, тип NullableRef фактично дозволяє методу мати параметр out ref T, який не може бути виражений в C# іншим чином. Планується також розширити поверхню API цих типів у майбутньому, щоб ці типи могли стати простою у використанні альтернативою GC-ref арифметиці з використанням типу Unsafe, яка також може бути візуально більш схожою на традиційну арифметику з вказівниками.

 

Крім того, всі типи ref-структур, яких ще не було у попередньому перегляді, було оновлено для внутрішнього використання полів ref для покращення продуктивності. До них відносяться:

Інші зміни 

У цьому новому випуску набагато більше змін!

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

Розпочинайте прямо зараз! 

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

Більше ресурсів 

Якщо ви хочете дізнатися більше про MVVM Toolkit, ви також можете переглянути це відео з нещодавньої конференції .NET Conf 2022, де показано, як можна використовувати MVVM Toolkit, новий генератор коду та всі нові функції в 8.1:

Існує ціла екосистема доступних Toolkit’ів з безліччю корисних API для створення .NET-додатків! Дізнайтеся більше про них у документації MS learn!

 

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

Source



Posted on 9. November 2022

Анонс .NET Community Toolkit v8.1.0 Preview 1

Анонс .NET Community Toolkit v8.1.0 Preview 1

 

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

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

 

Щоб дати короткий огляд того, що мстить інструментарій .NET Community Toolkit, наведемо перелік бібліотек, з яких він складається:

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

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

Ось перелік основних змін, які ви можете очікувати в цьому новому випуску.

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

Однією з найбільш запитуваних функцій (див. #208, #217, #228) для генератора вихідного коду MVVM Toolkit була підтримка використання користувацьких атрибутів для [ObservableProperty]. Було запропоновано декілька проєктів для підтримки цього, і врешті-решт було вирішено використати наявну властивість: синтаксис у C#, який дозволяє розробникам позначати атрибути для розповсюдження на згенеровані властивості. Це дає нам декілька переваг:

 

  • Він використовує вбудований синтаксис C#, що робить функцію “рідною” і не потребує додаткових атрибутів
  • Це розв’язувати проблему анотування атрибутів, які можуть бути спрямовані лише на властивості, а не на поля
Тобто, у MVVM Toolkit 8.1 тепер підтримується наступний сценарій:
Після цього буде згенеровано наступну властивість за лаштунками:

 

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

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

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

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

Як вже було сказано, ця нова попередня версія також містить значну оптимізацію продуктивності MVVM Toolkit, щоб ще більше покращити UX для розробників, особливо при роботі над дуже великими рішеннями. Команда провела багато часу, покращуючи архітектуру всіх генераторів і спілкуючись з інженерами з команди Roslyn, щоб переконатися, що виконується все можливе, щоб отримати від них максимальну продуктивність.

Ось лише деякі з удосконалень в цьому напрямку:

 

  • Додано багатоцільове націлювання для Roslyn 4.3 (#428, #462): генератори вихідних текстів MVVM Toolkit тепер використовуватимуть ціль Roslyn 4.3, якщо воно підтримується, щоб вони могли підключитися до деяких оптимізованих API, якщо хост це підтримує. Це автоматично вмикається при посиланні на MVVM Toolkit.
  • Використано ForAttributeWithMetadataName (#436): було переключено генератори на новий високорівневий API Roslyn для зіставлення атрибутів, що значно покращує продуктивність генераторів, які спрацьовують за певними атрибутами. Наприклад, [ObservableProperty] тепер використовує це.
  • Перенесено діагностику в діагностичні аналізатори (#433, #434): перенесено майже всю діагностику в діагностичні аналізатори, які виконуються поза процесом і незалежно від генераторів джерел. Це значно зменшує накладні витрати при наборі тексту, оскільки вся логіка діагностики тепер виконується в окремому процесі й не може сповільнювати роботу IntelliSense.
  • Припинено використання символів у інкрементних провайдерах (#435): оновлено всі інкрементні провайдери, щоб більше не поширювати символи. Це може зменшити використання пам’яті, оскільки розповсюдження символів може призвести до того, що Roslyn надмірно викорінюватиме об’єкти компіляції.
  • Більше оптимізацій продуктивності (#447, #460, #469, #487, #489): переглянуто всі наші інкрементні моделі та інкрементні конвеєри, щоб значно покращити продуктивність та зменшити виділення пам’яті.

 

Розширення месенджерів IObservable 

 

Ще однією функцією, яку просили розробники, особливо ті, що активно використовують API у стилі Reactive у своїх додатках, була можливість об’єднати функціональність API месенджерів у MVVM Toolkit. Тепер це підтримується завдяки новим розширенням IObservable для інтерфейсу IMessenger. Ви можете використовувати їх наступним чином:
…І це все! Це розширення створить об’єкт IObservable, який можна використовувати для підписки на повідомлення і динамічної реакції на них. Також підтримується вказівка різних токенів за допомогою окремих перевантажень. Ось ще один приклад, що демонструє наскрізне використання нового API:

Підтримка .NET 7 та C# 11 

Цей новий попередній випуск .NET Community Toolkit також додає .NET 7 TFM до пакета HighPerformance і містить кілька змін, що дозволяють скористатися новими можливостями мови C# 11, зокрема, полями посилань.

Наступні типи більше не знаходяться в режимі попереднього перегляду, вони були оновлені відповідно до нових правил безпеки арбітрів:
Приклад того, де вони можуть бути використані, наведений нижче:
Тобто, тип NullableRef фактично дозволяє методу мати параметр out ref T, який не може бути виражений в C# іншим чином. Також планується розширити поверхню API цих типів у майбутньому, щоб ці типи могли надавати просту у використанні альтернативу GC-реф-арифметиці з використанням типу Unsafe, яка також може бути візуально більш схожою на традиційну арифметику з вказівниками.

Інші зміни 

У цьому новому випуску набагато більше!

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

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

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

Більше ресурсів 

Якщо ви хочете дізнатися більше про MVVM Toolkit, ви також можете переглянути це відео з останньої конференції .NET Conf Focus on MAUI, яка відбулася раніше в цьому році, де показано, як можна використовувати MVVM Toolkit і всі нові функції генератора вихідних кодів для створення MAUI-додатків:

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

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





Posted on 9. November 2022

Адаптуйте WCF-додатки до найновіших версій .NET за допомогою CoreWCF та Upgrade Assistant

Адаптуйте WCF-додатки до найновіших версій .NET за допомогою CoreWCF та Upgrade Assistant

 

У цьому блозі розглянемо досвід міграції за допомогою Upgrade Assistant на простому WCF-проєкті.

Демонстрація міграції

Приклад Калькулятора – це дуже простий WCF-приклад, який складається з клієнтського та сервісного проєктів. Сервіс – це консольний додаток, який надає клієнтам сервіс CalculatorService. Він має дві кінцеві точки, одна з яких з прив’язкою netTcpBinding, а інша з прив’язкою mexHttpBinding, щоб увімкнути служби метаданих. Оскільки між клієнтом і сервісом немає проєктної залежності, можна оновити сервіс до CoreWCF на .NET 6 або .NET 7 безпосередньо за допомогою Помічника з оновлення.

Помічник з оновлення .NET – це інструмент командного рядка, який може оновити вашу програму до останньої версії .NET. Щоб встановити Upgrade Assistant, введіть наступну команду:

Після успішного встановлення інструменту ми можемо розпочати оновлення, запустивши його на файлі з прикладом рішення Калькулятора. Оскільки WCF Updater є розширенням за замовчуванням, нам не потрібно додавати жодних додаткових команд для завантаження розширення.

Після вибору CalculatorService як точки входу, інструмент згенерує список кроків оновлення, які потрібно виконати.

 

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

Міграція CoreWCF

 

Після завершення кроку 6: Додайте файли шаблонів, крок оновлення WCF буде ініціалізовано, і інструмент перевірить, чи можна оновити проєкт.

Якщо проєкт не відповідає вимогам або не може бути застосований, крок оновлення WCF буде пропущено і буде показано як завершений. Проєкт CalculatorService є застосовним, тож ми виберемо команду “1” для застосування кроку. Нижче наведено консольний вивід застосування кроку оновлення WCF.


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

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

Результати процесу конвертації

1. Оновлення файлів вихідного коду – service.cs

System.ServiceModel, пов’язані з використанням директив, замінено на директиви CoreWCF. Також додано простір імен ASP.NET Core, оскільки оновлений код використовує ASP.NET Core як хост сервісу.

У методі Main використовуємо хост ASP.NET Core замість об’єктів ServiceHost.

Також налаштовано деякі підтримувані поведінки служби тут, а не у файлі конфігурації, наприклад, метадані служби та поведінку налагодження служби.

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

2. Оновлення конфігураційного файлу

Налаштування, пов’язані з WCF, з App.config копіюються до новоствореного файлу wcf.config:

Розділ system.serviceModel в оригінальному App.config переміщено до цього новоствореного файлу wcf.config.

Усередині wcf.config такі секції, як та , закоментовано, оскільки вони налаштовані у вихідному коді.

3. Оновлення файлу проекту CalculatorService.csproj

Оновлюємо SDK до Microsoft.NET.Sdk.Web, щоб увімкнути хост ASP.NET Core.

Посилання на пакунки, пов’язані з System.ServiceModel, замінено на CoreWCF.

Вимоги до автоматичного оновлення

Зразок калькулятора, продемонстрований вище, є дуже простим випадком, і  розширення CoreWCF зараз здатне підтримувати лише певні типи WCF-проєктів. Попередній перегляд CoreWCF Upgrade Assistant наразі підтримує:

 

  • Оновлення WCF-проєкт з одним екземпляром ServiceHost і замінення його на хостинг ASP.NET Core.
  • Оновлення WCF-проєкту з декількома сервісами й всі ServiceHost створюються і налаштовуються одним і тим же методом.

 

 

  • Оновлення оригінального конфігураційного файлу у проєкті та генерування нового конфігураційного файлу для CoreWCF.

 

Заміна простору імен System.ServiceModel та посилання на нього на CoreWCF у .cs та файлах проєкту.

Він не підтримує:

 

  • WCF-сервер, який розміщується на вебхостингу і використовує файл .svc.
  • Налаштування поведінки за допомогою xml-файлів конфігурації, крім serviceDebug, serviceMetadata, serviceCredentials (clientCertificate, serviceCertificate, userNameAuthentication та windowsAuthentication)

 

 

  • Кінцеві точки, що використовують прив’язки, відмінні від NetTcpBinding та прив’язок на основі HTTP

 

Щоб проєкт WCF можна було застосувати для цього оновлення, він повинен відповідати наступним вимогам:

 

  • Містити файл .cs, який посилається на System.ServiceModel і створює новий ServiceHost.
  • Якщо WCF-проєкт має декілька ServiceHost, всі хости повинні бути створені одним і тим же методом.
  • Містить файл .config, який зберігає властивості System.ServiceModel.

 

Підсумок

Якщо у вас виникли проблеми з розширенням, будь ласка, створіть проблему в репозиторії Upgrade Assistant на GitHub з тегом area:WCF.