Bringing Universal Windows Platform apps to .NET 9

Microsoft’s journey to today’s Windows App SDK and Win UI as a unified framework for building .NET desktop applications hasn’t been smooth. Today’s platform brings modern tools and designs to familiar frameworks, but it’s hard to update older code built on Windows 10’s Universal Windows Platform (UWP).

A descendent of the WinRT model introduced with Windows 8, the Universal Windows Platform was designed to support new Windows APIs and the Microsoft Store. Tying distribution to the Microsoft Store was seen as an issue as it locked you into Microsoft’s application approval process and its own payment platform.

Over time the platform and the store have evolved, first allowing Win32 applications and games and now adding support for third-party payment platforms and distribution. The current model is flexible and designed to work with the latest .NET features.

Getting ahead with AOT

We’re about a month or so from the release of .NET 9, and the first release candidate is now available, along with a beta release of a .NET 9-ready version of Visual Studio. As part of this set of releases, Microsoft has delivered additional tools to bring older UWP-based applications to the .NET 9 platform, helping you to take advantage of new features such as native Ahead Of Time (AOT) compilation.

This option is important: .NET was originally designed for all its languages to compile to an intermediate byte code, which could then be interpreted by its runtime. That model is still at the heart of .NET, with just-in-time compilation tools supporting rapid conversion to binary code on both X64 and Arm64 devices.

.NET’s native AOT tooling lets your code compile as native binaries, ready for packaging and distribution, speeding up app launch. It does mean having to produce separate binaries for both X64 and Arm64, and often separate installers, though you can use a tool like Advanced Installer to build a multi-architecture installation that will install the correct binary for your user’s PC.

Bringing UWP to the Windows App SDK

Updating UWP applications to the Windows App SDK takes time, especially if you’re relying on third-party libraries and components that haven’t been updated to it or to Win UI 3. Although you can still distribute them through the Microsoft Store, you’re shut out from features like native AOT.

Microsoft would certainly like you to update your code to the latest version of the .NET stack, but it’s keenly aware of the difficulties. What’s needed is a way to take that existing code and run it on the latest .NET, changing what you can as you have the time and resources. That’s why it’s launched a set of tools to add UWP support to the upcoming .NET 9.

UWP support for .NET 9 isn’t a “one button” solution. Instead, it’s a mix of tools that work at different layers of the .NET development stack, in Visual Studio, in the Windows SDK, and in .NET itself. Together they provide the necessary scaffolding to bring across your existing C# code and start the migration process to the Windows App SDK, while still letting your users see some of the advantages of a more modern platform. Updates to newer technologies can be incremental, for example, developing a Win UI user experience while retaining some functionality in XAML Islands. As a result you’re actually taking advantage of a public release of tools that Microsoft is using for its own app updates, with the Microsoft Store working with these tools to deliver a native AOT version in the near future—most likely in November, after .NET 9 reaches general availability and gets support.

There’s another good reason to use this tool: It removes dependencies on the old .NET Native tooling. .NET Native reduced access to newer .NET features, as it hasn’t been updated beyond .NET Core 2.0 and .NET Standard 2.0. This change should allow you to add newer libraries to your code, giving access to a wider range of both .NET and Windows features.

Getting started with UWP in .NET 9

As always with preview code, setting things up is a little complex. Start with the latest preview build of Visual Studio 17.12. Once installed, use the stand-alone Visual Studio installer to ensure you have the Windows application development workload enabled. At the same time, add its UWP tool and the latest Windows 11 SDK release from the Other section of the installer.

The next prerequisite is only temporary: You’ll need to download and install a new XAML compiler. This will be included in a future release of the Windows 11 SDK, but for now it needs to be updated out-of-band. Another key requirement is the current nightly build of .NET 9, as the necessary tools will only start being packaged as part of the standard preview builds with RC2. Usefully Microsoft provides a nuget.config file that can be added to your application project to keep your .NET up to date with the current nightly build.

Another out-of-band install adds new project templates to support .NET 9-hosted UWP applications. Again, these should be in Visual Studio closer to release. It’s all pretty normal for a Microsoft development tool that’s a couple of months from release; there are a lot of moving parts in component-based tools such as .NET and Visual Studio, so you shouldn’t be surprised that they’re not on the same schedule yet.

You can now use the new project templates to work with UWP in .NET 9. It’s probably easiest to start with a blank template and bring across existing code and XAML. It behaves much like the original UWP template, while getting you ready to start a Win UI migration. Other templates should help with other scenarios, including applications that use Direct X or build new libraries.

Still plenty of work for you

Working with a UWP project in .NET 9 is much like working with it in older versions of .NET. You get the familiar application structure, with support for the latest MSIX application packages. You should note that some changes need to be made to the generated project file because there will be build errors as some unnecessary files are referenced by default.

The key to using UWP in .NET 9 is some properties that are set in the .csproj file. These enable UWP without conflicting with Win UI, as well as ensuring that the Visual Studio build tool uses the correct XAML compiler. Another necessary property ensures your code is compiled as native AOT so it can be published in the Microsoft Store. This is the only way to avoid store restrictions.

There will be issues here with updating code. You need to make sure that all your code, even libraries you’re using, works with native AOT. This can be a complex process, and while necessary, will be time-consuming. If you don’t deal with this, your UWP applications are unlikely to work in .NET 9. Much of what’s necessary is part and parcel of a migration from .NET Native to native AOT, as the two technologies handle validation differently. Native AOT is much stricter, using static validation and code annotations. This helps avoid bugs, although it does require some effort, even following Microsoft’s migration documentation.

Although many of the tools here are focused on helping support your code through a transition from UWP to modern Windows App SDK applications, other scenarios are supported. One of the more interesting is improving how XAML Islands work, helping you host existing UWP controls in a modern Win32 application. With UWP support in .NET 9, you can have your Win32 code and your control in the same project, using the same build tools. There’s no longer any need to manage XAML Islands controls separately from the rest of your code.

There’s a surprising amount of functionality in this tool, and you’re likely to find more features as you start exploring it. Bridging the gap between two different application development models does more than keep code up to date, it helps show developers that they aren’t being left behind in favor of the newest technologies. It’s also useful to know that Microsoft itself is using these tools; it’s how the Microsoft Store is moving from UWP to the Windows App SDK and Win UI 3.

Don’t expect everything to work right now. Some key tools are missing, like the XAML designer, so you can’t work with application layouts at present. Work is underway on a new designer, and it should be available at launch. Missing features are to be expected at this stage; this is a preview release running on preview code.

As Microsoft notes, these tools aren’t intended for building new UWP applications, as tempting as this might be. For one thing, UWP is no longer under development, so new Windows features and capabilities won’t be available to your code. Still, it’s an acknowledgement that old code won’t be left behind and that we need an effective upgrade route from the old to the new.