Comments 24
Зачем заморачиваться с WinForms, если уже столько лет есть WPF? Дайте ему уже благополучно загнуться.
WF часто используют там, где нужно за пару кликов накидать UI для чего-нибудь, без сложного дизайна и без заглубления в XAML. И не всегда это делают профессиональные разработчики.
Слышал, что таким промышляют во всяких лабораториях, чтобы сделать UI для какой-нибудь экспериментальной установки.
Ну и ещё всякое легаси есть.
VB Net же всё ещё не закопали )
Самым удивительным является тот факт, что WinForms сейчас гораздо живее WPF. Если поглядеть на GitHub репозиторий WPF, то большинство коммитов сейчас делается автоматическим копированием зависимостей с WinForms.
В общем это даже понятно. WinForms является оберткой над Win32 API, а это в некотором смысле основа десктопа Windows.
А вот WPF Microsoft старательно закапывает ради нового продукта под названием Win UI 3, надстроенного над новым Windows App SDK, который является в некотором смысле реинкарнацией невзлетевшего UWP.
Но пока Win UI 3 крайне сырая и медленная. Более того, многих возможностей WPF там нет, и не скоро появятся. В частности довольно удобная 3D графика WPF в WinUI 3 не факт, что вообще когда-нибудь появится.
Так что если что-то сейчас писать для Windows декстопа, то вариантов то почти нет. WPF Microsoft старательно убивает, WinUI может вообще не взлететь. Писать на JavaScript под Electron? Или ReactNative?
С этой точки зрения WinForms живее всех живых.
А вообще, я бы рекомендовал Qt для нового декстоп проекта под Windows.
Qt - это ведь для C++, а не для .Net, насколько я знаю.
В целом да, Qt это для C++. Хотя у них есть QML/QtQuick для написания UI на основе декларативного JavaScript.
Но огромный плюс Qt это очень стабильный API для кроссплатформенного декстопа. Qt было, есть и будет. Хотя и на C++.
А вот что и когда Microsoft решить закопать в следующий раз, это большой вопрос. Начинать проект на WPF сейчас крайне рискованно. Команду WPF почти разогнали и не факт, что восстановят. Пулл-реквесты висят годами.
А WinUI 3 где-то раз в 100 медленнее WPF.
И что делать?...
Ну, если так рассуждать, то тогда вместо Qt лучше сразу смотреть в сторону asp net core 6 ( оно всё таки своё, родное). Интерфейс в браузере, а сам бэкенд хостить в докер-контейнере. Собственно так и делаю уже несколько лет. Печально, что WPF прикопали. Мне он нравился и я лелеял надежду, что его всё же сделают кросплатформенным, вопреки заявлениям.
Самым удивительным является тот факт, что WinForms сейчас гораздо живее WPF.
Совершенно согласен — удивительно, но так и случилось.
MS пытались изменить ситуацию на рынке технологий, но технологии живут своей жизнью и даже создателю не всегда под силу этим процессом управлять.
Неплохо бы портировать WinForm на Linux, типа как Mono но от корпорации.
Потому что WPF не лучше WinForms. Да, в некоторых местах он шагнул далеко вперёд: темплейты, стили, анимации, свойства и события прокачались, разметку теперь не нужно переписывать при изменении DPI или языка (ну ладно, хотя бы не так часто и геморройно). Но в некоторых вещах (RichTextBox и WebBrowser) он просто не юзабелен, только WindowsFormsHost и спасает...
P.S.: ~10 лет опыт работы с WPF, ~5 лет WinForms.
Ну вот как не лучше-то? Например, WPF элементы поддерживают перекрытия за счёт коэффициента прозрачности. WinForms такого не умеет. В WPF интерфейс можно делать очень красивым, гораздо красивее, чем WinForms (при условии, что есть талант по части стилей). Всякие анимашки, "вау"-эффекты, даже 3D-интерфейсы можно делать. Всё это обрабатывается видеокартой (DirectX). Для WinForms графика обрабатывается центральным процессором. Чтобы сделать красивый "вау"-интерфейс средствами WinForms придётся попотеть гораздо больше и ещё не факт, что всё получится.
Да, "из коробки" элементов в WPF не так много, как хотелось бы, однако самому создавать кастомные элементы на WPF гораздо легче/удобней, чем для WinForms, а это многого стОит... К тому же, если организация ценит своё время, то вообще может купить разработчику расширенный набор WPF-контролов (например от DevExpress, хотя то же самое можно сказать и в копилку WinForms).
В Windows есть WinForms и WPF, при этом оба никуда не денутся, ибо проверены годами и широко используются. WPF гораздо развитей, поэтому я не вижу смысла использовать WinForms в новых проектах. На мой взгляд, использование WinForms при наличии возможности использования WPF, это как покупка персональных, именованных граблей, на которые придётся часто наступать.
WPF сложнее в изучении в виду того, что подлежащей освоению информации гораздо больше, чем для WinForms (это минус).
Крис Андерсон, будучи архитектором WPF, лаконично, но достаточно понятно излагает материал по WPF. Мэтью Мак-Дональд и Чарльз Петцольд делают это более фундаментально (Петцольд больше с уклоном на код, а Мак-Дональд - на XAML и потому, на мой взгляд, гармонично дополняют друг друга).
В то же время по WinForms, насколько я помню, есть только одна старая, толковая книжка (всё от того же Чарльза Петцольда).
Насколько больно будет мигрировать проект на WinForms, написанный на VB.net, который сейчас работает под .Net Framework 4.0? Кто-нибудь сталкивался с подобными задачами?
Так он скорее всего у вас WinForms и использует. Или имеется ввиду портировать с VB.Net на C#? Для последнего есть утилиты, но чистить код и поправлять всё равно придётся. Переносил проект с VB.Net с .Net Framework 3.5 на С# .Net Framework 4.
По моему опыту - это лотерея. Если кода, ипользующего подкапотные костыли .NET и WinForms мало, то вполне возможно, что удастся реально обойтись заявленным в статье Application.SetDefaultFont. Шаг в сторону (не ту) - здравствуйте, две недели отладки. Мигрировал по версиям 2 своих pet-проекта и 2 крупные enterprise-системы. Ни разу не угадал с прогнозом сложности таких изменений - причём ошибался в обе стороны.
Все прекрасно, но что с Linux?
Раньше была поддержка Winforms от Mono, но еще в .Net 5 вы все сломали
Там у майков есть MAUI и коммунити пишет Avaloniaui
Ни то, ни другое, насколько я знаю, с Winforms несовместимо. И в моем случае, вы предлагаете мигрировать весь проект. И это можно было бы сделать, но есть два НО:
1) До этого все работало в Mono. (Есть мелочи, но это действительно мелочи)
2) До этого Microsoft похоронила WPF, Silverlight, плиточный дизайн. Сейчас занята тем, что активно закапывает UWP. И да, MAUI официально Linux не поддерживает, это отдано на откуп энтузиастам.
Есть ещё кроссплатформенный Eto.Forms
Как насчёт - platform.uno
platform.uno, насколько я понял, это тоже XAML. Для существующего немаленького проекта, переходить на него - это переписывать GUI с нуля.
В Eto.Forms, что мне понравилось - так это то, как решается вопрос встраивания в уже существующие проекты.
Также API похож на оный у Winforms, поэтому миграция проходит гораздо плавнее.
Что нового в Windows Forms в .NET 6.0