Але справа не лише у доступі до більшого об’єму пам’яті. Перехід на 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