Project Reunion: Why Desktop Developers Care

Project Reunion was renamed the Windows App SDK in version 0.8.5.

Project Reunion is intended to consolidate the APIs for the various versions of Windows into a single API. If you’re a desktop developer, even in preview, Project Reunion is already delivering tools that you could be using. And if you’ve ever thought about UWP, then you care very much.

Let me give you some idea of how old I am (but keep reading anyway): When I started creating desktop applications using Microsoft tools, using Windows Forms because it was the only tool available, I had a copy of Dan Appleman’s Visual Basic Programmer’s Guide to the Win32 API. I thoroughly enjoined reading it and learned a lot about Windows in the process. How long ago was that? Part of the book covered how to convert 16-bit calls to 32-bit calls.

Yes, that old.

However, other than the odd call to exchange strings with C DLLs, I never really used the information in that book. All my UI and application development needs were met with Windows Forms, the UI controls that came bundled with it, the Windows COM libraries I could add to my projects and the third-party ecosystem that grew up around Windows Forms.

Since then, we’ve had several different versions of Windows and several different development platforms (WinForms, of course, but also WPF, .NET and UWP). I’ve been able, through various controls and libraries, to remain isolated from the underlying API changes.

The Problem

But there are developers (and you may be one) who haven’t been isolated from those API calls. This is especially true of, for example, the developers who built all those great Windows Forms controls and libraries I used in my applications. The developers who (just to pick some examples at random) developed the Telerik UI for WinForms toolkit. Or the Telerik UI for WPF toolkit. Or the Telerik for UI for Universal Windows Platform (UWP) toolkit. Or the upcoming Telerik UI for WinUI toolkit. And all the other desktop tool vendors are in the same boat.

Part of the reason there are so many toolkits (or, to put it another way, the problem facing those toolkit developers) is the proliferation of Windows 10 APIs—supporting UWP, for example, means supporting the WinRT APIs. This isn’t a trivial task, even on Windows 10 and even with the improved NuGet-based support. Even with that support, developers still have to write version-adaptive code if they want to support earlier versions of WinRT.

And, as desktop developers, you and I care also. If we only accessed UI controls, that might not be true. But we also use various libraries to access non-UI resources like, for example, GeoLocation. The experience of working with GeoLocation in the .NET Framework is very different from doing it in UWP with its WinRT support (in fact, until .NET Framework 4.0, the only way to access GeoLocation was to use WinRT libraries).

But what if those WinRT APIs weren’t segregated? What if there was a single set of APIs available everywhere? All of a sudden, all of these development tools would achieve functionality parity—everyone would support GeoLocation and in the same way (syntax differences aside). More importantly, life would get considerably easier for the developers creating all those wonderful tools, which means more wonderful tools. And, as the growth of cross-platform tools like Xamarin, MAUI, UWP and WinUI shows, there is a craving for a development platform that crosses multiple (if not all) platforms. That becomes a lot more achievable if there’s only one API.

Project Reunion

This is why you care about Microsoft’s Project Reunion and the products it’s already delivering. Project Reunion is intended to consolidate access to Windows features under a single API. In theory, it could mean the end of UWP as a separate development platform: Everything would run everywhere because everything would look alike.

That’s probably too much to expect. But, having said that, Project Reunion has only just got to the 0.5 Preview stage and already includes a unified API for DirectWrite, which provides device-independent text layout. That’s not something you might use directly—instead, you’d count on your UI controls to take care of getting your text on the screen (just like I never wrote to the screen directly when I was creating Windows Forms apps).

But Preview 0.5 also includes MRTCore, a set of objects in the Microsoft.ApplicationModel.Resources namespace for managing resources, including both file resources (files holding bitmap images, XAML, XML, HTML, etc.) and embedded resources (resources in a Resources file like .resw or .resjson). MRTCore objects include ResourceLoader, ResourceManager (which wraps the ResourceMap object, which lists all of your resources) and ResourceContext (which, through ResourceCandidate objects, makes the relevant resources available to your object). That’s a set of objects you could be using tomorrow.

If you want to try out these new tools, your best choice currently is in a WinUI project. WinUI, which allows you to create applications that run both on Windows and WinRT, makes sense for the rollout of Project Reunion (and WinUI is worth trying out for its own sake). Hopefully, the tools that Project Reunion makes possible will become available to all of Microsoft’s desktop development environments—which has the potential of being pretty terrific. Even if I never make an API call in my life.