The Universal Windows Platform, which inherits the WinRT model introduced in Windows 8, was designed to support new Windows APIs and the Microsoft Store, but it was pointed out as a problem that it tied distribution to the Microsoft Store, making it dependent on Microsoft’s application approval process and its own payment platform.
Over time, the platform and stores have evolved, first accepting Win32 applications and games and now adding support for third-party payment platforms and distribution. The current model is flexible and designed to be compatible with the latest .NET features.
Get ahead with AOT
In about a month, .NET 9 will be released. The first release candidate and a Visual Studio beta version supporting .NET 9 are available now. As part of this release, Microsoft is also releasing additional tools to bring older UWP-based applications to the .NET 9 platform, so that you can take advantage of new features like ahead-of-time (AOT) compilation.
This option is important. .NET was originally designed so that all languages would be compiled to an intermediate byte code, which could then be interpreted at runtime. This model is still central to .NET, with just-in-time (JIT) compilation tools providing fast conversion to binary code on both X64 and Arm64 devices.
.NET’s native AOT tools can speed up app releases by compiling your code into native binaries, which can then be packaged and distributed immediately. Of course, you’ll need to build separate binaries for X64 and Arm64, and often separate installers, but tools like Advanced Installer can build multi-architecture installers that install the right binaries for the user’s PC.
Bringing UWP to the Windows App SDK
Updating UWP applications to the Windows App SDK can take time, especially if they depend on third-party libraries and components that haven’t yet been updated to the Windows App SDK or Win UI 3. You can distribute them through the Microsoft Store, but then you won’t be able to take advantage of features like native AOT.
Of course, Microsoft wants developers to update their code to the latest version of the .NET stack, but it’s also understandable that it’s difficult. That’s why we need a way to take existing code, run it on the latest .NET, and make changes when we have time and resources. For this reason, Microsoft has released a set of tools that add UWP support to the upcoming .NET 9.
UWP’s support for .NET 9 is not a “one-button” solution, but rather a mix of tools that work across multiple layers of the .NET development stack, across Visual Studio, the Windows SDK, and within .NET itself. These tools work together to provide the foundational elements needed to take existing C# code and begin the migration process to the Windows App SDK, while allowing users to see the benefits of the modern platform. Updates to newer technologies can be made incrementally, for example, allowing Win UI user experiences to be developed while retaining some functionality in XAML Islands. As a result, Microsoft will be leveraging the publicly available versions of the tools it uses to update its own apps, and the Microsoft Store will work with these tools to provide native AOT versions soon (probably sometime in November when .NET 9 is officially released and supported).
Another good reason to use this tool is that it removes dependencies on older .NET Native tools. .NET Native has not been updated beyond .NET Core 2.0 and .NET Standard 2.0, so it cannot use new .NET features properly. This change allows you to add new libraries to your code, allowing you to use more .NET and Windows features.
Getting started with UWP in .NET 9
As is always the case with preview code, setup is a bit complicated. First, start with the latest preview build of Visual Studio 17.12. Once installed, enable the Windows Application Development workload using the standalone Visual Studio installer. Also, add UWP Tools and the latest Windows 11 SDK release from the Others section of the installer.
The following is a temporary requirement that requires you to download and install the new XAML compiler, which will be included in a future Windows 11 SDK release, but must be updated separately for now. Another important requirement is the latest nightly build of .NET 9, as the required tools are packaged in the standard preview build of RC2. You can keep .NET up to date with the current nightly build by adding a nuget.config file provided by Microsoft to your application project.
Another separate install adds a new project template to support UWP applications hosted on .NET 9. This will also be included in Visual Studio as it gets closer to release. This is common for Microsoft development tools months before release, as component-based tools like .NET and Visual Studio have many moving parts and can have different update schedules.
You can now get started with UWP in .NET 9 using the new project templates. It’s probably easiest to start with the blank template and import your existing code and XAML. It works almost identically to the original UWP template, and prepares you for a Win UI migration. The other templates will help with other scenarios, including applications that use DirectX or build new libraries.
There’s still a lot to do.
The process of using UWP projects in .NET 9 is very similar to previous versions of .NET. It uses the familiar application structure and supports the latest MSIX application packages. Note that you will need to make a few changes to the generated project file. This is because it basically references some unnecessary files and causes build errors accordingly.
The key to using UWP in .NET 9 are a few properties set in the .csproj file. These properties enable UWP without conflicting with Win UI and ensure that the Visual Studio build tools use the correct XAML compiler. Another required property ensures that the code is compiled natively AOT so that it can be published to the Microsoft Store. This is the only way to avoid store restrictions.
Here’s where the problem with updating code comes in. You need to make sure that all your code (even the libraries you use) is native AOT compatible, which is necessary, but can be complex and time-consuming. If you don’t do this properly, you’ll often find that your UWP applications won’t work properly on .NET 9. Much of the work that’s required is essential for migrating from .NET to native AOT, because the two technologies handle validation differently. Native AOT is much stricter and relies on static validation and code annotations. This helps prevent bugs, but it takes some effort, even if you follow Microsoft’s migration guide.
Many of these tools focus on helping you transition your code from UWP to a modern Windows App SDK application, but they also support other scenarios. One interesting scenario is improving the way XAML Islands work to host existing UWP controls in modern Win32 applications. With UWP support in .NET 9, you can keep your Win32 code and controls in the same project and use the same build tools. You no longer need to manage your XAML Island controls separately from the rest of your code.
There’s an incredible amount of functionality in this tool, and you’ll find more as you explore it. Bridging the gap between the two different app development models does more than just keep your code up to date. It helps show developers that you’re not leaving them behind in the face of the latest technology. It’s also helpful to know that Microsoft itself is using this code. The Microsoft Store is also moving from UWP to the Windows App SDK and Win UI 3 in the same way.
Don’t expect everything to work right away. Some of the core tools, such as the XAML designer, are missing, so you can’t do application layout work right now. The new designer is still in development and will be included when the full release is released. As this is a preview release running on preview code, the lack of features is something to be expected at this stage.
As Microsoft emphasizes, these tools are not intended for building new UWP applications. After all, UWP is no longer being developed, so you won’t be able to use new Windows features in your code. In any case, these tools are an acknowledgement that existing code won’t be thrown away, and that there needs to be an effective path to upgrade from old code to new code.
editor@itworld.co.kr
Source: www.itworld.co.kr
