WPF in 2021: alive, dead or on life support?

Recently I've been participating in a team discussion about whether or not to choose WPF as a framework for a new "greenfield" Windows-only application. The application itself isn't expected to have a sophisticated UI, but it might be required to use WebView2 and/or some 3rd party controls for document rendering, viewing and printing.

I'm writing this post as someone with substantial .NET/WPF background, who has lots of fond memories about WPF (and some bitter ones, too). I am not trying to diminish the value of this framework, but rather to evaluate where it stands nowadays in Microsoft Desktop development roadmap.

From what I could tell, these days even Windows Forms is getting more love from Microsoft than WPF. I hope I'm wrong, but I'm observing certain signs of WPF being currently either shelved or placed into a very low-maintenance support mode:

  • The WPF roadmap itself (or, pretty much, the lack of it, if compared to that of WinForms). According to this document, the only ongoing effort is "incorporating .NET Framework servicing fixes into .NET Core 3.1 and .NET 5".

  • "Is this repo dead" issue in the WPF repo. Lots of interesting comments in that thread, particularly, this one:

    The real reason was already communicated on community calls over on YouTube. The team was merged with WinUI and created from zero, apparently everyone from the original team is gone, and the new team is very resource constrained so they don't manage to deliver more than a couple of fixes. Now we can complain that instead of doing WPF, WinUI, MAUI, Blazor on Electron (what a bad idea!) they should focus on just having one UI-vnext framework, but after UWP failure, they don't seem to be able to decide what to do, each group talks differently about the "vision".

    Some folks in that thread even voiced initiatives to fork WPF and maintain it independently of Microsoft.

  • Microsoft's Igor Velikorossov on what's new in Windows Forms:


    It's great to see WinForms being actively maintained, but what about WPF? Check out the grieving readers' comments. Back then, Microsoft's PM Premalini David replied with a promise of boosting up the WPF team internal resources. Looking at the WPF repo commit history now, that doesn't seem to have been happening yet.

  • "What's new in WPF for .NET 5" on docs.microsoft.com. Actually, this page doesn't exist for .NET 5, it falls back to the .NET Framework 4.x content, when you choose ".NET 5". Besides some information on adding ARM CPU support, I couldn't find any details about what's new in WPF since it got ported to .NET Core 3 in 2019.


    On a side note, the "what's new" section does exist for .NET 5 Windows Forms.

I expected WPF to be an ultimate container for hosting WebView2, to help modernizing the enterprise desktop WPF apps, which typically still use the legacy IE11-based WebBrowser control. As of now, this is far from being the case, either:

Overall, while there are some ongoing efforts from other teams at Microsoft to continue supporting WPF as a platform (that includes WebView2, BlazorWebView, XAML Islands, Visual Studio Designers), the WPF GitHub repo itself has been very quiet lately.

What's on Microsoft's own radar for Windows-only UI development these days? Well, the official future path appears to be WinUI 3. It was in the spotlight during Build 2021 and the recent Windows 11 presentation event. The modern Windows Terminal app — a big open-source hit enjoying a well-deserved recognition — is built with WinUI and mostly in C++.

Microsoft also seems to be big about WebView2 for the apps where HTML UI is shared between Web and Desktop. The upcoming Teams 2.0 is a good example of such approach, it's a thin WinUI host for WebView2. I ranted with more details about the new Teams 2.0 architecture (TLTR: it doesn't use .NET on the client side at all).

Apparently, Microsoft is also well invested into React Native for Windows (a very active repo) and Fluent UI framework (used by Office 365).

For .NET folks who want to stick with C# for sharing HTML UI between Web and Desktop (with little or no JavaScript/React/etc), Microsoft will be releasing WebView2-based BlazorWebView, supported on WinForms, WPF and .NET MAUI:

Using Blazor and a hybrid approach you can start decoupling your UI investments from WPF & Windows Forms. This is a great way to modernize existing desktop apps in a way that can be brought forward onto .NET MAUI or used on the web. You can use Blazor to modernize your existing Windows Forms and WPF apps while leveraging your existing .NET investments.

This sounds like a .NET version of Electron on steroids to me. At this stage, it isn't something I'd like to take for a ride with a new Desktop project, unless there is already a working Blazor SPA web app to wrap as a desktop app. I've tried BlazorWebView with a simple WinForms-based app, and currently (as of NET 6 Preview 7) it doesn't feel close to the production quality yet. Nevertheless, BlazorWebView is an impressive piece of technology, I hope it will mature and won't be abandoned.

Besides, the UI technologies Microsoft use for their own mainstream projects aren't necessarily always what they recommend to the rest of the dev world. This can be a particularly confusing domain at the moment, just check this Twitter thread by Jerry Nixon, a Microsoft engineer:

I'd also highly recommend reading Nick Randolph's "The Future of Windows (and Other Platforms) Development". It's a great take at clarifying the confusion in the fragmented space of various Windows UI frameworks.

To wrap it up, there is a whole array of frameworks and meta-frameworks to choose from for Windows desktop development nowadays, including some cross-platform options (visit crossplatform.dev for a concise overview). A .NET developer can choose from:

... and more. Back to our specific app case, I personally voted for Windows Forms, as odd as it may sound in 2021.

Some pro-WinForms points:

  • it is old and battle-tested but still being actively maintained (unlike WPF, presently);

  • has a simple, unopinionated and well-know API;

  • uses native Win32 UI controls under the hood and therefore …

  • … is easy to integrate with other native and managed controls or modernize with WebView2, BlazorWebView and/or XAML Islands. I'd expect fewer issues with the focus/keyboard interop as well, or at least, they should be easier to address, than with WPF.

  • can be abstracted behind something simple, like Model-View-Presenter Pattern, or something advanced, like Reactive UI;

  • can be deployed as a single EXE (~75MB) without needing admin rights, Windows Store, packaging, sideloading, tweaks to the Windows Developer settings, etc (updated: trimming no longer work in .NET 6 for WinForms/WPF):

    dotnet new winforms -n app

dotnet publish app -r win-x64 -c Release --self-contained true -p:PublishSingleFile=true -p:PublishTrimmed=True -p:IncludeNativeLibrariesForSelfExtract=true -p:TrimMode=Link

dir /s app.exe

I've been using the .NET Core reincarnation of WinForms for #DevComrade, a small side project. It enables systemwide pasting without formatting by default, amongst a few other productivity improvement features. Building it with WinForms has been a very positive experience so far.

Some late updates:

Thanks for reading! Feel free to leave a comment below or on Twitter.

14

Tags:

DotnetDesktopWpfWinforms