The production version of WinUI 3 is scheduled to come out by the end of March (by the time you read this, it may already be out).
Yay?
Between WinUI, WPF and/or Windows Forms for .NET Core, and MAUI, it’s possible that it may not be obvious which framework you should pick when building your next desktop app. And I’ve omitted at least two Microsoft technologies: Xamarin (because it’s going to be absorbed into MAUI) and Blazor desktop (because it is/will be built on top of the MAUI stack). I’m also ignoring Project Reunion because (a) it’s only in version 0.1 and (b) isn’t intended to replace development tools but to consolidate APIs across Windows platforms.
Even with taking those tools off the table, that’s still a lot of frameworks in play. And it’s probably not going to get better: Richard Lander commented recently that he doesn’t see a “Grand Unified App Model” in the near future. And, as a principal program manager on the .NET Core team, you’d think he’d know.
In all honesty, it might not be the smartest choice (in some sense of the word “smart”) to just keep using whatever toolset you’ve been using so far to build your next desktop app. But it is a choice that has you working with a technology you understand well.
But if you’re willing to consider going to something new … well, WinUI might be your best next choice. Among other benefits (including a very up-to-date developer experience), the version due out in March extends WinUI from supporting the Universal Windows Platform to covering all the Windows device families: Windows 10, Xbox One, Surface Hub, Windows Store, etc. That’s not cross-platform (for Android/iOS/MacOs, you want MAUI), but it may be all you want.
Still, why abandon what you already know? The good news here is that you may already know a lot of WinUI because WinUI is a XAML-based tool. That news gets better: If you’re a WPF developer (or have been using XAML with Windows Forms), then you can adopt WinUI incrementally by exploiting XAML islands. This is also true if you’ve been using React Native, Xamarin.Forms or the Uno Platform.
So, if it’s not going to be painful or expensive, it’s worthwhile to consider what you would get by building in WinUI. The short answer is a modern, fluent development experience (that means Hot Reload so you can see your changes without stopping and restarting your debugger) and a toolkit that exploits all of Windows’ functionality (that means new controls that reflect what current users expect in their UIs—the WinUI controls are a lot more touch-friendly, for example). You can start to get a glimpse of the new controls in this screen grab of the Xaml Gallery (you need Visual Studio to see the gallery in interactive mode). And you can take advantage of the Telerik WinUI toolkit for performant and state-of-the-art controls to extend that gallery.
If the release version isn’t out yet, you can try your luck with the previews (I’ll explain why you need to be lucky in a little bit).
You’ll need the .NET 5 SDK and Visual Studio 2019 Preview 9.2 or later—as I write this, that preview page is downloading Preview 10. In theory, when installing Visual Studio, checking off the .NET Desktop Development should give you the .NET 5 SDK, but that didn’t happen with me. Check to see if the WinUI 3 project templates are present and, if not, download them.
To get the full benefit of the new user experience, from Visual Studio’s Tools menu, select Options | Environment | Preview Features and select Enable UI Debugging Tooling for WinUI 3 Projects. This turns on Hot Reload for XAML files. If you’ve worked with Live Property Tree and Live Visual Tree when building WPF apps, both are still available from Debug | Windows.
When you go to create your project, you’ll have your pick of WinUI project templates for creating any one of desktops apps, class libraries and WinRT components with C++ either for UWP or for Desktop. As I write this, if you want to try out the toolset, I’d recommend “Blank App (WinUI for UWP)” because I couldn’t get any of the “WinUI for Desktop” templates to work (the combination of Visual Studio and WinUI previews has turned out to be a moving target that’s surprisingly hard to hit).
After your app is created, press F5 to start it running and—for some XAML Hot Reload action—then return to Visual Studio, make a change to your XAML file, save your change, switch back to your app and see your change already up and running (changes to your code file will require you to stop and start your debugger).
When the Desktop templates are working, you’ll find that the “create project” experience has a new wrinkle: You’ll be asked for the version of Windows you want to target and for the oldest version of Windows you want support. These two options set the TargetPlatformVersion and TargetPlatformMinVersion settings in your application so you can use those settings to enable and disable functionality, depending on which version of Windows your app is running on (the “oldest version” setting basically specifies what you’re not willing to give up).
It’s a cool technology and, if you’re building Windows desktop apps (and, especially, if you have any WPF/XAML experience), it could well be your future.
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter also writes courses and teaches for Learning Tree International.