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:
- For .NET 5: https://devblogs.microsoft.com/dotnet/whats-new-in-windows-forms-runtime-in-net-5-0.
- For .NET 6 Preview 5: https://devblogs.microsoft.com/dotnet/whats-new-in-windows-forms-in-net-6-0-preview-5
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:
Rick Strahl's blog post about his titanic efforts on integrating WebView2 into his WPF-based Markdown Monster Editor:
https://weblog.west-wind.com/posts/2021/Apr/15/WebView2-Forwarding-Alt-Keys-to-a-Host-WPF-Window.
My own struggle with WPF + WebView2 keyboard and focus issues:
https://github.com/MicrosoftEdge/WebView2Feedback/issues/468#issuecomment-855810839. I believe that can't be properly resolved without making changes on the WPF side.
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:
- WinForms
- WPF
- UWP (but be sure to read this announcement)
- WinUI
- Xamarin/MAUI
- BlazorWebView
- Windows Community Toolkit (with MVVM Toolkit)
- Uno Platform
- Avalonia
- Comet
- ReactiveUI
- Chromely
- EdgeSharp
- Electron.NET
... 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,BlazorWebViewand/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:
- Microsoft's announcement about .NET 5/6 support not coming to UWP .NET projects.
- My take on the above UWP announcement.
- No trimming support for WinForms and WPF projects in .NET 6.
- An interesting thread on HN, discussing current the state of UI development with .NET, amongst other things.
- "The roadmap is outdated" issue in WPF repo.
- I learnt that WPF is still used in Microsoft's Powertoy project and in the new Visual Studio Installer (migrated from Electron), not to mention VS2022 itself (still a .NET Framework 4.x project though).
- There's hope that WPF team will eventually get a much needed resource boost (although still no signs this is happening, as of Nov'21):
Thanks for reading! Feel free to leave a comment below or on Twitter.
Top comments (13)
I don't think it's of much worth trying to enumerate every available option, except for the mere purpose of being exhaustive. Most of them are there just because of history. If you want to go with "legacy" because of familiarity, then WPF and WinForms are the ones, you already know them. Otherwise, I think it's rather clear:
Of course some of these frameworks are in preview phase, but if you're starting now and planning for the mid-term they could be sensible choices.
Indeed, I listed some frameworks for completeness, but I'd add at least two strong contenders to your list:
Uno Platform. What they're doing is quite amazing, basically, C#/.NET/WinUI XAML for pixel-perfect UI that works on desktop, mobile and even web (via WASM).
Example: playground.platform.uno/#grid
Avalonia UI - mature and well supported.
Both are actively maintained and supported by consultancy business and active contributing communities built around them (unlike presently WPF).
I deliberately didn't include React Native because it isn't based on .NET stack (a prerequisite for this research), same as Flutter. The latter would probably be my personal choice if I needed a true cross-platform solution (not just Windows Desktop).
I was focusing on what Microsoft seems to suggest as alternatives (including Electron, even though there is nothing MS specific there, but you can always add some FAST fluent components...). Of course, Uno is great, but I didn't know about Avalonia, thanks for the suggestion!
I mostly see cosmetic, ported-from-4.8 fixes in the WPF repo. But even that is a good sign, it was mostly a GitHub bot updating dependencies a month ago, when I published this article.
NET 4.8 is still maintained with monthly service releases (and will be through 2029, IIRC). Apparently they're back-porting 4.8 WPF fixes to .NET 5/6. There are no new WPF features, and I imagine these fixes are largely driven by VS2022, which is still based on .NET 4.8.
BTW, FAST.design is fantastic, yet Microsoft uses Fluent UI for O365 HTML UI. Looks like there's a lot of internal competition inside Microsoft in the space of UI frameworks, but WPF isn't a part of it.
Office 365 uses React and its components probably predate FAST. There is a port of the office Fluent components to Blazor github.com/BlazorFluentUI/BlazorFl.... There is some interesting discussion regarding the relationship of Fluent UI components and FAST here github.com/dotnet/aspnetcore/issue.... That issue was closed after the creation of a new project with FAST wrappers for Blazor github.com/microsoft/fast-blazor.
Thanks! The discussion link is golden, I haven't come across it until now. A great read.
Regarding WPF, after reading your posts I checked their GitHub and I did find reasonable activity, at least for a mostly legacy framework it has a decent share of commits. Also there are a couple of maintained Metro/Fluent themes open source projects for a face-lift. Although I wouldn't go there for a green field project.
Tks, I just had another look at the WPF repo, commented above :)
I feel you :)
Thanks for article.
We have a huge application in WPF and I feel that WPF will not continue, due to its complexity in styling, the overall cumbersomeness, which is increasingly showing compared to other tools. I would appreciate if there was a way to convert a WPF application into anything that can live on. But this would only be possible in part, because no one can programmatically convert insanely complicated nested styles with its insane bindings in visual trees. I see the WPF as a trap today.
Glad you liked the article. Perhaps, the less drastic way to modernize a legacy WPF app would be to start converting it incrementally, view-by-view, to WinUI, using WinUI XAML islands. However, if you're really looking for something that would live on, and want to stay in .NET ecosystem, you may want to evaluate Blazor/Desktop. Historically, ASP.NET dev space has had a lot less friction than .NET UI dev space.
I also find this HN thread a relevant and interesting read.