Sometimes, being a Microsoft developer seems like Mark Twain’s old joke about the weather. You know the one — if you don’t like the API they’ve given you today, wait a week and try the next one.
My favorite example of Microsoft’s constant reinvention is database APIs in the late 1990s, when they unleashed an alphabet soup of different three-letter technologies (RDS, DAO, ADO, OLE DB). But in the decade since, no one has suffered more than business developers trying to write graphical Windows applications.
Two decades of Windows applications
When .NET 1.0 first hit the scene, life was straightforward. If you were a .NET developer who wanted to build a Windows desktop application, you used Windows Forms. It was easy (almost VB-like in its drag-and-drop simplicity), and relatively feature-complete. Yes, you might need to work around the odd limitation and make a call to the Win32 API every once in a while. But if you wanted a straightforward line-of-business application that looked respectable and didn’t need custom chrome, the world was a good place.
Then things took a turn. Microsoft knew they could never incrementally improve their way out of the limitations baked into Windows Forms — things like poor support for high-DPI displays, and weak performance with custom rendering. There was no built-in way to do 3D, animation, partial transparency (thanks, Vista), or any of the things that were considered to be cutting-edge UI at the time. So Microsoft launched a massive reinvention project called WPF (Windows Presentation Framework).
WPF changed almost everything, from the way windows were defined (now declaratively, using an XML grammar called XAML) to the hardware underpinnings (DirectX, the same technology that powers high-performance games). WPF’s new features were impressive enough to keep programmers on board, though some of the changes were painful. For example, the first release of WPF had no way to drag-and-drop a basic window into existence — a feature that had existed in the Microsoft world since the first version of Visual Basic.
WPF was successful, but not successful enough to replace the dead-easy, run-everywhere Windows Forms toolkit. So both technologies coexisted — one as a mature platform for legacy apps, and the other as the best place for new, future-facing development. And for a while, this seemed like a reasonable compromise.
The problem was that UWP was hardly universal. Yes, it ran across different types of Windows 10 devices, unlike WinForms or WPF, but it didn’t support any previous version of Windows. This single fact was enough to discourage established developers from making the jump to UWP. Even if they didn’t need the features of a full desktop application written in something like WPF, they didn’t want to lock themselves into a smaller box of computer compatibility.
That brings us to the state of Windows development today. All three frameworks for Windows desktop applications still coexist, filling slightly different niches. On top of that, developers are still maintaining C++ applications built on MFC and the Win32 API.
Enter Project Reunion
For a while, it seemed like Microsoft was just waiting out the era of desktop computing, hoping its loyal developers would eventually trade in their windowed applications for a web-based framework like Blazor. But at this year’s Build conference, Microsoft pulled back the curtain on a new strategy to gradually harmonize their different desktop models. That journey starts with something called Project Reunion.
Project Reunion is a move to decouple and share the user interface parts of UWP. In other words, Microsoft is separating the UI toolkit from UWP (called WinUI 3) so that it can be used in other types of applications. Yes, you can still use WinUI to make UWP applications, which still run in their sandboxed environment (even if they don’t need to be deployed through the increasingly-sidelined Windows Store). But — more importantly — you can also use the WinUI toolkit in other types of applications. In fact, you can use it with all the Windows application frameworks Microsoft spent the last two decades creating, from legacy MFC applications to WinForms and WPF.
This is valuable, because WinUI includes controls for building Fluent user interfaces — a web-influenced style of design that helps you create modern, beautiful interfaces. Thin borders, transitional animations, and reflowable layouts are some of the hallmarks of Fluent UI.
If you spent the last few years ignoring Fluent UI because it also came with a bunch of extra baggage — like the Windows Store and a sandboxed environment — you no longer have to pay that tax. Now you can build a .NET 5 desktop application with full hardware support that uses the WinUI library.
However, there is a catch. Like UWP, WinUI requires Windows 10. That appears to rule it out for the large swath of developers still supporting fossilized business environments — but maybe not. That’s because Microsoft has plans to extend WinUI compatibility back to Windows 8.1. And it’s not just a pie-in-the-sky hope. Microsoft needs Windows 8.1 compatibility to support the Windows React Native project, which also uses WinUI.
The big questions are obvious. How can you migrate a WPF or WinForms app to WinUI? And should you?
Even though WinUI is compatible with older types of desktop applications, its user interface model is different. There’s compatibility, but not harmony. One path to migration is to refactor as much code as possible out of your UI, and then graft on a new WinUI-built skin. Another option is to go piecemeal. A single application can combine windows that use WinUI with windows that use WinForms or WPF, using a technique called XAML Islands. This gives you a way to tiptoe slowly into the future (but it also guarantees that your application will have a somewhat schizophrenic visual style that jumbles together the old fashion and the new). Either way, Microsoft promises solid IDE support. For example, not only will you be able to easily add WinUI views to a WinForms or WPF project, you’ll also be able to use project templates that mix together the different UI frameworks.
The next question is obvious — is it ready?
Today, WinUI 3 exists in a public preview version. It’s good enough to start playing with, or even planning your next release. But it isn’t ready for production. Planned features, like Xbox and HoloLens support, are still lacking. The final release of WinUI 3 is set in November, at the same time as .NET 5.
It remains to be seen whether WinUI 3 is a case of too little too late. After the partial failure of UWP, many desktop developers moved on to making desktop apps with web technologies like Electron. But for those who need to remain in the Windows desktop world, the path to the future looks more promising than it has in years. Sanity has returned to the crowded world of desktop APIs. And the next step forward isn’t another completely new framework, but an attempt to reunite what we already have.
For a once-a-month email with our best tech stories, subscribe to the Young Coder newsletter.