Understanding Project Reunion (Premium)

For the past few years, I’ve hoped that Build would finally provide a bit of clarity for Windows developers. This year, it happened. And I gotta tell you, I feel pretty good about it.

Granted, I’m still struggling to process the firehose of information that Microsoft just sprayed in our collective faces. But that’s a good thing: While Build will continue to be dominated by Azure news, there was plenty of news for those of us more concerned about the client. And not just Windows 10 specifically, but Microsoft Edge and Microsoft 365 too. It was a nice change.

For now, however, I’d like to continue focusing on the Windows app development story and, more specifically, on Project Reunion, Microsoft’s (temporary?) name for this new effort. Yesterday, I wrote my introductory post about this push forward. Today, I’d like to expand on that information by explaining what I’ve learned since then from both Microsoft and my hands-on experiences.

Project Reunion is the new name for a strategy that Microsoft has been working on for years and began quietly hinting at last year at Build 2019. At that time, a certain Microsoft executive who asked for their comments to be off the record started planting the seeds for Reunion by declaring that the Universal Windows Platform (UWP) was “dead” and that the Microsoft Store would be deemphasized going forward.

This year, we have a lot more clarity of both of these moves. And while I won’t focus on the Store story here, the short version is that the Microsoft Store will become a graphical front-end for the new app package manager technology that Microsoft also announced this week.

So, what is Project Reunion really?

Project Reunion is a modern replacement for UWP and a way to use APIs that were previously locked into UWP in other developer frameworks, including Win32/C++, Windows Forms, Windows Presentation Foundation (WPF), and React Native.

There are two Project Reunion components today: WinUI, which provides the UX components previously locked in UWP, and WebView2, which allows developers to embed web technologies in native apps. (WebView1 was based on legacy Edge, while WebView2 is based on the new Edge.) Microsoft says that it will strip more APIs out of UPW and add them as Project Reunion components based on developer feedback.

I can’t imagine that there’s anything else of value in UWP, but whatever: The UX components are excellent, and given that I recently created multiple versions of .NETpad across WinForms, WPF, and UWP, I can state with certainty that the one thing from UWP I do want to use in the other versions of the app is the UX stuff. And I can already see exactly how this will work.

If you’re a developer and want to get started yourself, Microsoft has some instructions here. But the short version is that you need four things: The Visual Studio 2019 Preview (version 16.7 Preview 1), .NET 5.0 Preview 4 x86, .NET Preview 4 x64, and the WinUI 3.0 Preview 1 VSIX extension for Visual Studio.

Once you have that up and running, you can create the following new types of apps in Visual Studio:

WinUI Desktop. This is the new “Windows app,” a modern Win32 application with a UWP/XAML (UX) front-end. Basically, this is like UWP without any of the limitations of UWP, including the awful mobile platform nonsense that hobbles these apps on desktop today.

WinUI UWP. This is basically the new UWP, and it will eventually be made to work on other Windows 10 platforms like HoloLens. As such, it’s only useful for that tiny subset of developers who either want to target multiple Microsoft platforms or just target a single platform, like HoloLens. This is a way forward for those folks.

(In addition to this, you can also create WinUI class libraries, Windows Runtime components, and the like.)

What you can’t do, not in Preview 1—Microsoft tells me this is coming soon, perhaps by Preview 3—is open an existing WinForms or WPF project in Visual Studio and add WinUI capabilities. But even in this broken first preview, I can see exactly how it will work. And it’s pretty cool.

Consider the WPF version of .NETpad. This application consists of a main application window (literally, MainWindow.xaml), plus a few sub-windows/dialogs, like FontDialog, InputBox, and AboutBox. Each of those windows was created in the WPF version of XAML, and each contains various controls, like menus and buttons, each of which is served by event handlers and other custom functions/methods.

To port this application project to Project Reunion, I need to do the following:

Upgrade from .NET Core 3.1 to .NET 5.0. This actually does work today, and the application works fine after this change.

Add a WinUI Desktop window to replace each WPF XAML window. Oddly, Visual Studio does let you add WinUI blank windows today (plus WinUI-based pages, custom controls, resource dictionaries, resource files, and user (custom) controls), but then the project won’t compile. This is what’s broken now, and what will be fixed in a future release.

Recreate the UX in each WinUI Desktop window. Now, I’m going on theory, since it won’t compile. But from here, you basically just recreate the UX from your old window(s) in the new WinUI Desktop window(s). In many cases, I suspect you can just copy and paste the XAML, though there are some big differences between WPF/XAML and UWP/XAML controls. For my app, this will be pretty straightforward, except for the statusbar.

Link each control in the new windows to the event handlers from the old windows. Here, again, this will vary according to what you’re doing. But if you think about something like a File > New menu item, the New menu item in the new window could just point to the same Click event handler used by the New menu item in the old window. Repeat (updating the code as needed) until everything in the new window works. I created a way to launch the new window for testing, but again, nothing works yet.

Replace the old window(s) with the new WinUI Desktop window(s). Once it all works, you just swap in the new for the old. When you do this for all the windows, you’re done: Your old app has a new, modern UX.

Granted, this is overly-simplifying things, but that’s how it will work, I think. And I’m really excited to see this in action and to be better understand the difficulties that will no doubt come up. It will happen soon enough.