WPF i Windows Forms: czy dawny .NET dla pulpitu jeszcze żyje?

Rewolucja w środowisku .NET, polegająca na zamrożeniu rozwoju .NET Framework i przejściu w całości na wieloplatformowe oprogramowanie .NET Core (dziś po prostu ".NET"), przypadła na czasy, gdy tworzy się w nim już głównie zaplecze techniczne C# dla aplikacji ASP.NET. Feeria narzędzi do tworzenia aplikacji desktopowych zakończyła się tym, że albo stosuje się dziś klasyczne kontrolki natywne (ewentualnie z własną nakładką) albo po prostu sięga po Electron i interfejs webowy. Czy to oznacza, że dawne cudowne rozwiązanie rodem z Longhorna - WPF i jego poprzednik Windows Forms, umarły śmiercią naturalną?

Migracja na .NET Core miała miejsce już dobre kilka lat temu, to nie jest nic "nowego". Ale przez długi czas wersja "Core" nie zawierała większości składników z dawnego frameworka. Powoli pojawiały się "core-owe" inkarnacje znanych składników. Entity Framework otrzymywał Entity Framework Core, na przykład. Środowiska uruchomieniowe dało się także mieszać, celując nie w jedno API, a w ".NET Standard". Pomysł ten na szczęście jest już przeszłością.

Z biegiem lat, wersje "Core" otrzymały także składniki, które w ogóle nie były priorytetem, a wśród nich właśnie Windows Forms oraz Windows Presentation Foundation. Nie są one portem celującym w Framework, a nową wersją, działającą z .NET 5 i 6. Osiągnęły zbieżność funkcjonalną ze swoimi poprzednikami i obecnie są domyślnym targetem rozwiązania w Visual Studio. Dostępny jest także Projektant Form.

Niewątpliwie główną częścią prac nad przygotowaniem wersji "Core" dla Formsów i WPF było przeniesienie projektu rozwijanego po staremu na nową metodykę… wszystkiego. Nowe CI, nowe QA, nowy hosting kodu (GitHub), nowe sposoby raportowania błędów, otwarty kod źródłowy i nowe API. Ten kawał roboty wykonano wzorcowo i aplikacje celujące w .NET Framework ze swoim interfejsem zazwyczaj da się "po prostu przenieść" na Core, są do tego przewodniki z Microsoftu i wskazują na to, że raczej nie jest to bolesna migracja.

Niewątpliwie pozwala to dalej utrzymywać bardzo stary kod w zbieżności z najnowszymi wersjami .NET, co jest niezwykle istotne. Dobicie do ściany w postaci porzuconych API, nierozwijanych bibliotek i niekompatybilnych interfejsów często wymusza bowiem albo drogi refactoring albo porzucenie projektu i rozpoczęcie pracy od nowa. Tymczasem w przypadku .NET, możliwe jest utrzymywanie kodu o dwudziestoletnim rodowodzie. O ile oczywiście w międzyczasie nie za-nugetowaliśmy zbyt wielu zależności, które odmawiają przebudowywania się na nowych dotnetach…

Czy zatem Core-owe wersje WPF i Formsów nie są niczym ponad wysoce niewdzięczną "utrzymaniówkę", czyli projekt bez szans na nowości, za to przebudowywany z najnowszymi API? Póki co - jeszcze tak. Dlaczego "jeszcze"? Wynika to z tego, co jest obecne na roadmapach obu projektów. WPF informuje o integrowaniu poprawek z .NET FX 4.8, pracach nad wzrostem wydajności oraz nowym procesie dla pull requestów. Planowane jest także otwarcie infrastruktury testowej. Czyli zero nowych funkcji. Z tym, że…

Wysiłek na taką skalę nieco wykracza poza niezbędne minimum utrzymaniówki. W przypadku .NET Core istnieją składniki o wiele gorzej utrzymywane, na przykład Visual Basic. Obecnie żadna funkcja wymagająca adaptacji pod VB lub wymuszająca na VB rozszerzenie składni, po prostu nie otrzyma obsługi tego języka. Może będzie się budowało, a może nie. VB ma działać tylko ze zbiorem tych rzeczy, z którymi działało kiedyś. ASP.NET Core z VB zatem odpada.

W WPF wkładane jest więcej wysiłku. Zapewne nie przełoży się to na żadne nowe funkcje, ale można mieć względną pewność, że wybranie WPF nie jest toksycznym pomysłem. A więc WPF zapewne nie jest przyszłościowe, ale wybranie go jako UI nie powinno być strzałem w stopę. Podobnie, jak (z czym większość programistów .NET zdecydowanie się nie zgodzi!) Windows Forms. Kto wie, może jest to rezultat słabej wiary pokładanej w MAUI, czyli nowy wieloplatformowy (pod względem architektur, systemów i urządzeń) zbiór API dla GUI w .NET.

Co zabawne, nowe funkcje są wspomniane dla Windows Forms, czyli fraktalnie niemal archaicznego rozwiązania. Formsy nie wykorzystują natywnych kontrolek Windows ani elementów Common Controls 6. Implementują wszystko po swojemu. Dlatego Wstążki i powiadomienia bąbelkowe albo nie istnieją albo są nędzną namiastką natywnych. Roadmapa informuje o tym, że zbierane są głosy poparcia dla inicjatywy rozbudowania ich implementacji.

Choć szanse są na to niskie, byłaby to dobra wiadomość. Wszak niezależnie od tego, jakie są trendy w tworzeniu aplikacji (wszystko jest webowe!) oraz interfejsów (po prostu wlejmy UI w Electrona!), Windows Forms pozostaje naszybszą metodą na sklecenie "byle jak" szybkiej aplikacji. Nie każdy program musi od razu iść w świat. Kiedyś użytkownicy komputerów mieli w zwyczaju samodzielnie pisać programy. Dziś jest to urokliwie utrudnione…