To build applications with the Windows App SDK, you will need the following:

• A computer with the latest version of Windows 10 or Windows 11.
• Visual Studio 2022 with the following workloads:
• Universal Windows Platform (UWP) development
  • .NET desktop development
  • Desktop development with C++
• The Windows SDK version 2004 (build 19041) or later. This SDK will be installed with Visual Studio when you enable the UWP development workload.
• The .NET 6 SDK. This SDK will be installed together with Visual Studio when you enable the .NET Framework desktop development workload.
• The Visual Studio extension for the Windows App SDK (if you are using Visual Studio 2022 Update 1 or later, it will already be included).

The code for the chapter can be found at the following URL:

https://github.com/PacktPublishing/Modernizing-Your-Windows-Applications-with-the-Windows-Apps-SDK-and-WinUI/tree/main/Chapter01

Over the years, UI guidelines and paradigms have constantly shifted as hardware and platforms evolved. We moved from screens with 640 x 480 resolution to 4K or even 8K screens, from mouse and keyboard only to touch and digital pens. Consequently, Microsoft has created multiple UI platforms over time, with the goal of offering developers the opportunity to build modern applications; each of them represented the state of the art for the time when they were released.

The first platform was called Microsoft Foundation Class Library (MFC), which was a C++ object-oriented UI library released by Microsoft in 1992. It was a wrapper around most of the Win32 and Component Object Model (COM) APIs. Thanks to MFC, developers were able to build UIs with the most common Windows controls and build complex interfaces made up of multiple windows, panels, and so on. MFC was a considerable success, and it's still heavily used today by many developers. The following screenshot shows the look and feel of a typical MFC application:

Figure 1.1 – A Windows application that uses MFC as a UI framework

However, as years passed by, it started to show limitations in supporting modern devices and features such as high-resolution screens and touch inputs. Additionally, it can be used only by C++ developers, while many developers over time have migrated to managed languages such as C#, which are easier to learn and support.

In 2002, Microsoft released the first version of .NET Framework with the goal of improving developer productivity. By running applications inside a virtual environment called Common Language Runtime (CLR), developers could get out-of-the-box features such as security, memory, and exception handling that, in the past, needed to be manually managed. Additionally, by introducing languages such as C# and VB.NET, Microsoft reduced the learning curve required to master a programming language and start building software. As part of .NET Framework, Microsoft included a platform to build Windows desktop applications called Windows Forms. It's an event-driven platform, which makes it easier to build complex applications by wrapping the existing Windows UI common controls and Windows APIs in managed code. The development experience is mostly UI-based – developers create UIs with a visual designer by dragging and dropping the available controls inside a window. Then, they can write code that reacts to the events exposed by the various controls, such as the click of a button or the selection of an item from a list. The following screenshot shows the development experience provided by Visual Studio to build Windows Forms applications:

Figure 1.2 – The Windows Forms designer in Visual Studio

The platform kept evolving across the various releases of .NET Framework, until it reached full maturity with version 2.0.

With the release of .NET Core 3.0, Windows Forms has been integrated into the modern .NET development stack for the first time. This choice has enabled developers to access all the latest enhancements in the platform, such as newer versions of the C# language, performance improvements, or the latest Windows APIs. However, when it comes to building the UI, it still lacks many of the features you would expect from a modern platform, such as support for responsive layouts and new input experiences.

In 2006, as part of the release of .NET Framework 3.0, Microsoft unveiled Windows Presentation Foundation (WPF), the next evolution of the Microsoft UI platform. WPF introduced, for the first time, features that are still used today by modern UI platforms (including the Windows App SDK), such as XAML (which stands for Extensible Application Markup Language), binding, and dependency properties. WPF still supports building the UI with a designer, but it isn't as essential as it was for Windows Forms. WPF, in fact, decouples the UI from the business logic by describing the UI with XAML, an XML-based language. Additionally, WPF added support for features such as 2D/3D rendering, hardware acceleration, animations, and vector graphics. As with Windows Forms, .NET Core 3.0 welcomed WPF as a first-class citizen in the new development platform, enabling WPF developers to get access to the latest versions of runtimes, languages, and developer tools. Compared to Windows Forms, WPF is a more robust UI platform, capable of delivering more modern experiences, as you can see in the following screenshot:

Figure 1.3 – MSIX Hero is a good example of an application that delivers a great user experience by using the WPF capabilities

However, it still has limitations, such as poor support to high Dots-Per-Inch (DPI) devices, touchscreens, digital inking experiences, and accessibility.

In 2015, with the release of Windows 10, Microsoft released UWP, which is an extension of Windows Runtime that was introduced in Windows 8. UWP is a modern development platform that enables developers to build secure and robust applications that run inside a sandbox; it gives access to all the new features added in Windows 10, such as tiles, notifications, and Windows Hello; it's based on a new UI platform called Fluent Design, which offers built-in support to responsive layout, touch and digital pen, accessibility, and so on. Many built-in Windows applications, such as Microsoft Store, are built with UWP and WinUI:

Figure 1.4 – Microsoft Store in Windows is a UWP application

In the first releases of UWP, the UI framework (like all the other development APIs) was built in the operating system. Over time, this approach created multiple challenges, both to Microsoft and developers:

• Despite Windows 10 adopting a much more aggressive update strategy compared to prior versions, by releasing two upgrades per year, it still forced the development team to address issues and add new UI controls and features only twice per year.
• If a developer wanted to use the new UI controls or features added to the latest version of Windows 10, all their users had to upgrade their machines to that version as well. This was a challenge, especially in enterprise environments, where the upgrade pace is slower than in the consumer world.

To overcome these challenges, in October 2018, Microsoft released the first public release of the Windows UI library, called WinUI 2.0. With this release, Microsoft detached most of the UI controls and features from the operating system and moved them inside a library, which is distributed as a NuGet package. The library enabled Microsoft to release more frequent updates (the current life cycle is four releases per year) and developers to get access to the latest UI enhancements without forcing their user base to upgrade to the latest Windows 10 version.

Now that we have learned a bit of the history of the Microsoft development platform for Windows, we can better understand how the Windows App SDK fits into the story. We've learned that, over time, Microsoft has released new UI platforms with the goal of being state of the art at the time of release. However, UWP introduced a few challenges, especially for developers building line-of-business applications. UWP is a great fit for many consumer scenarios – the sandbox enables an application to run more safely, since it has limited access to critical Windows features, such as a registry or a full filesystem; thanks to a rich capabilities system, the user is always in control of which features of the device (a webcam, a microphone, location, and so on) an application can access; and thanks to a modern life cycle, applications are more respectful of the CPU, memory, and battery life of a device. In many cases, however, enterprises require deeper control and flexibility – applications need to always run, even when they are minimized in the taskbar; they need to interact with custom hardware devices and retrieve information from the Windows Registry.

Also, Windows Runtime, the application architecture behind UWP, introduced a few challenges. This modern runtime offers a lot of benefits: it's built in C++, which means it offers great performance; it's based on asynchronous patterns, which help developers to build applications that are fast and responsive; and through a feature called projections, it enables developers to consume Windows Runtime APIs from multiple languages, such as C++, C#, and Rust. However, since it's a significantly different platform compared to the ones already on the market (such as .NET), developers who have heavily invested in C++, Windows Forms, and WPF are able to reuse little or no code when porting their applications to UWP. This requirement created a lot of friction, since in the enterprise ecosystem, it's easy to find desktop applications with decades of development that are very hard, if not impossible, to port to UWP without rewriting them from scratch. The outcome is that even if developers loved Fluent Design and the new features introduced in Windows 10, most of them weren't able to take advantage of them.

In late 2019, Microsoft announced the first milestone to overcome these challenges – WinUI 3.0. Earlier versions of WinUI already started to lift most of the UI controls and features from the operating system, but the library was still targeting only UWP. With the 3.0 release, instead, Microsoft lifted the whole UI framework from the operating system, enabling other development platforms such as .NET to start taking advantage of the new UI library.

Thanks to WinUI 3.0, developers can now build modern applications and experiences but, at the same time, leverage familiar development platforms such as .NET or C++; reuse most of the investments they did building Windows Forms, WPF, or C++ applications; and use popular NuGet packages that they had already adopted in Windows Forms and WPF applications. Additionally, since applications using WinUI 3.0 are no longer dependent on UWP, but instead run as classic desktop applications, many of the features that enterprise developers saw as a constraint (the sandbox, the life cycle optimized to reduce CPU, and memory usage) don't apply anymore.

Microsoft, during the 2020 edition of the Build conference, officially shared the next step of the journey by announcing Project Reunion, a new development platform with the goal to provide developers with the best of both worlds – familiar developer frameworks and languages (such as .NET, C#, and C++) and the ability to use all the Windows features. WinUI 3.0 was incorporated into this new platform, and it became its first and most important building block.

Project Reunion continued to evolve over time by gradually bringing new features that were exclusively a part of UWP, such as push notifications and activation contracts. On June 24, 2021, when Microsoft revealed to the world Windows 11, the Windows development team announced the official name of Project Reunion – the Windows App SDK.

The Windows App SDK and WinUI 3.0 have the ambitious goal of becoming the new reference UI platform for all Windows developers, regardless of their background. In fact, the Windows App SDK targets both C++ developers (who, before the Windows App SDK, were stuck on MFC as the UI framework offered by Microsoft) and .NET developers (who can reuse their existing skills but target a more modern UI framework than Windows Forms and WPF).

The Windows App SDK introduced the following advantages for developers:

• Consistent support: Windows and its development platform continue to evolve over time, and developers must rely on techniques such as adaptive coding to keep a single code base and use a specific feature only if the application is running on a version of the operating system that supports it. Over time, this approach can add complexity, so Microsoft decided to create the Windows App SDK with built-in down-level support. An application that uses the Windows App SDK can run from Windows 11 down to Windows 10, version 1809. Newer features will be automatically enabled if the application is running on the proper version of the operating system. An example of this feature is Mica, a new material introduced in Windows 11 to enrich the background of an application. If you configure your application to use it, Mica will automatically light up if the application is running on Windows 11, while it will automatically fall back to a solid color on Windows 10.
• A faster release cadence: Since the Windows App SDK is a library, Microsoft can ship updates faster, without being aligned to the release cycle of Windows.
• A unified API surface: Historically, the number of Windows features you could use in your application depended on your framework of choice. For example, many Windows 10 features were supported only by UWP apps. The Windows App SDK unifies access to Windows APIs so that, regardless of the app model you choose, you will be able to use the same set of Windows features.

The Windows App SDK and WinUI are considered the future of the Windows developer platform. UWP is now considered a stable and mature platform that will continue to receive security updates and be supported. However, all the investments for new features and scenarios will be focused on the Windows App SDK, making it the best choice to build future-proof Windows applications.

This book is dedicated to C# developers, and it will cover the usage of the Windows App SDK with classic desktop applications based on the .NET runtime. However, every concept you are going to learn can also be applied to C++ applications.

.NET Framework was introduced by Microsoft in 2002 with the goal to provide a better development experience and an easier learning curve for developers to build applications for Windows. These principles still hold true today, but the development landscape has changed significantly since 2002. New platforms have appeared, and Windows, in the server and cloud space, isn't the leading platform anymore; scenarios such as containers and microservices require a new level of optimization and performance, especially in key areas such as networking or filesystem access. Open source is now the new standard to release and evolve development platforms in collaboration with the community.

In 2014, Microsoft announced the first version of .NET Core, a new development platform based on the same principles of .NET Framework but open source, cross-platform, and lighter. The first versions of .NET Core were focused on key scenarios such as cloud services and web applications. With the release of .NET Core 3.0, Microsoft has started to invest also in the desktop ecosystem, by making Windows Forms and WPF open source and welcoming them into the new runtime.

However, the .NET ecosystem was still fragmented – if web and desktop applications could run on .NET Core, many developers were still using the full .NET Framework to build their solutions; Xamarin (the cross-platform framework to build Android and iOS apps with C#) and Blazor (the new platform to build client-side web applications using C# instead of JavaScript) were still based on Mono, the original open source implementation of .NET Framework. This fragmentation created multiple challenges over time and required the team to create solutions such as Portable Class Libraries and .NET Standard to enable developers to share code and libraries across different projects.

With .NET 5 (released in November 2020), Microsoft started an ambitious project to unify the entire .NET ecosystem. Instead of having multiple implementations of the framework for different workloads, .NET 5 started a unification journey, with the goal of supporting all the platforms and devices on the market with a single runtime and base class library. .NET 6 is going to complete this journey with a future update by abandoning Mono and bringing Xamarin (now known as .NET for Android and .NET for iOS) inside the family.

The new .NET runtime has also introduced a more predictable release plan, which makes it easier for developers to plan the adoption of one version or another:

1. .NET 5 was released in November 2020.
2. A new version will be released around the same time frame each year – for example, NET 6 was released in November 2021, and .NET 7 will be released in November 2022.
3. The releases with an even version number (.NET 6, .NET 8, and so on) are marked Long-Term Support (LTS). These releases will be supported for 3 years, so they're a better fit for projects that need stability.
4. The releases with an uneven version number (.NET 5, .NET 7, and so on) are supported for 6 months until the release of the next version – for example, .NET 5 will go out of support in May 2022, 6 months after the release of .NET 6. You can check the most up-to-date support policy at https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core.

By adopting a more frequent release cycle, the .NET team can be more agile and reduce the chances of introducing breaking changes between one version and the other. Even if you decide to adopt a .NET runtime that is not marked as LTS, in most cases, the transition to the next release will be smooth, with no or very few code changes needed.

Consequently, .NET Framework reached the end of the journey with the release of .NET Framework 4.8. This framework is still popular today, and as such, Microsoft doesn't have any plan of deprecating it. The current .NET Framework support policy is tied to the Windows one, so .NET Framework will continue to be supported for a long time. However, it won't receive any new features or major updates. If you're a developer building Windows apps that are continuously upgraded and evolved, the suggested path forward is to migrate your .NET Framework applications to the new .NET runtime so that you can take advantage of the constant evolution of the platform.

For all these reasons, the new .NET runtime plays a critical role in our journey. Since the Windows App SDK is the future of Windows development, its evolution is deeply connected with the new .NET runtime. For example, the first preview releases of the Windows App SDK were targeting .NET 5, but the platform is now aligned with the most recent .NET 6 release.

Additionally, all the features exposed by the Windows App SDK don't support the old .NET Framework, but they require the new .NET runtime.

The Windows App SDK has currently reached version 1.0, and it includes the following features:

• WinUI 3
• Text rendering
• Resource management
• App life cycle
• Power state notifications
• Windowing
• Push notifications (preview)

The second section of this book will be focused on WinUI 3 and will guide you toward a modernization journey, with the goal of evolving your application from your existing UI framework (Windows Forms, WPF, or UWP) to embrace the latest innovation in Fluent Design.

This feature of the Windows App SDK is currently supported only by new apps that target WinUI 3. This means that this modernization journey will help you to reuse most of your existing code and libraries (thanks to the .NET runtime), but you won't be able to gradually move the UI of your Windows Forms or WPF application. You will have to use one of the new Visual Studio templates to create a new .NET application based on WinUI. Microsoft is working to bring a technology called XAML Islands to WinUI 3, which will instead enable developers to gradually migrate the UI of their applications by mixing controls from WinUI with controls from the existing UI frameworks (Windows Forms and WPF).

The third section, instead, will be focused on the developer platform – you will learn how to integrate the other features offered by the Windows App SDK, plus many other new APIs (such as geolocation and machine learning), which, previously, were available only to UWP applications. These features, unlike WinUI 3.0, can be easily integrated into existing desktop applications built with WPF and Windows Forms, as long as they have been migrated to at least .NET 5.

The Windows App SDK is distributed in three different channels:

• Stable: The releases distributed through this channel are supported in production environments. They include the latest stable and tested bits.
• Preview: The releases distributed through this channel include preview features that will be added in the next stable release. Being a preview, they aren't supported in production scenarios, since there might be breaking changes when the stable version gets released.
• Experimental: The releases distributed through this channel include experimental features, which might be discarded or completely changed in the next stable release. They aren't supported in production environments, since the included features might not even see the light.

All the features described in this book are included in the stable channel, except for push notifications, which are still in preview.

With an understanding of the Windows App SDK, our next step is to learn how to choose between an unpackaged and packaged deployment model. We will do that in the next section.

We'll talk in more detail about how to deploy distributed applications that are using the Windows App SDK in Chapter 11, Publishing Your Application, but it's critical to introduce at the beginning two important concepts, since they will influence the way you create an application – packaged and unpackaged.

Packaged applications adopt MSIX as a deployment technology. MSIX is the most recent packaging format introduced in Windows, which, compared to other deployment technologies such as MSI or ClickOnce, brings many benefits:

• A cleaner install and uninstall process, thanks to the usage of a lightweight container that virtualizes many of the critical aspects of Windows, such as the filesystem and the registry
• Built-in features such as automatic updates even in unmanaged scenarios (such as a website), bandwidth optimization, and disk space optimization
• Tampering protection, which prevents an app that has been improperly changed from running and damaging an operating system

Windows applications packaged with MSIX are described by a manifest, which is an XML file that holds information such as the name, the publisher, the version number, and the dependencies. The packaged approach is the best one for applications that use the Windows App SDK, since it simplifies many of the scenarios that we're going to see in this book, such as managing the framework dependency and using Windows APIs that require an identity.

However, as a developer, you might face scenarios where a packaged app doesn't fit your requirements:

• The container provided by MSIX is very thin, but there are still situations when it might interfere with the regular execution of your application due to the isolation of the registry and the filesystem.
• To work properly, the application must deploy, during the installation, a kernel driver, or it must apply some global settings to the computer, such as creating environment variables and installing a Windows feature. The isolated nature of MSIX doesn't make these kinds of scenarios a good fit.

Because of these cases, the Windows App SDK also supports unpackaged apps, which are applications that you can deploy the way you prefer by using manual copy deployment, adopting a traditional MSI installer, building a custom setup, or using a script. The way you deploy your application is deeply connected to the way you manage the dependency that your application has with the Windows App SDK. Let's learn more in the next section.

By detaching features and APIs from the operating system, the Windows team has gained a lot of benefits, such as the ability to add new features and fix issues outside the regular Windows update cycle. However, as developers, we cannot take for granted that the user who installs our application will have the Windows App SDK runtime installed on their machine. As such, it's our responsibility as developers to manage this dependency in the right way. This is one of the scenarios where the difference between adopting the packaged or unpackaged model is critical, since they adopt two different ways to deploy the dependency.

The Windows App SDK runtime is made up of the following components:

• The framework package: This package contains the binaries that are used by the applications at runtime.
• The main package: This package contains multiple out-of-process components that aren't included in the framework, such as background tasks, app extensions, and app services.
• The singleton package: This package includes a long-running process that provides access to features that are shared across all applications, such as push notifications.
• Dynamic Dependency Lifetime Manager (DDLM): This package is used to control the life cycle of the Windows App SDK runtime. Thanks to this package, Windows will refrain from automatically updating the runtime if one or more unpackaged apps that use the Windows App SDK are running.

Each of these components is stored in its own MSIX package. Let's see now how to manage the deployment of the runtime based on the way you distribute your application.

Packaged apps

As previously mentioned, packaged apps have a few advantages compared to unpackaged apps. Packaged applications are described by a manifest, which includes a section called Dependencies. This section is already used today to manage the dependency on a specific version of Windows or the Visual C++ runtime.

The dependency with the Windows App SDK runtime can be easily declared in the same section by adding the following entry:

<PackageDependency Name="Microsoft.WindowsAppRuntime.1.0" 
  MinVersion="0.319.455.0" Publisher="CN=Microsoft 
    Corporation, O=Microsoft Corporation, L=Redmond, 
      S=Washington, C=US" />

Thanks to this configuration, if the application is deployed to a machine that doesn't have the runtime installed, Windows will automatically download it from the Microsoft Store and install it system-wide so that future applications that you might install won't need to download it again.

In most cases, you won't have to manually include this entry. In fact, when you install the Windows App SDK NuGet package in your application, Visual Studio will add a special build task that will add this entry in the manifest for you every time you generate a new MSIX package.

However, there's still a manual requirement you have to take care of. As mentioned in the previous section, the Windows App SDK applications are dependent not just on the framework itself but, based on the features they use (for example, background tasks or push notifications), they might also need the main package and the singleton package. MSIX doesn't support having regular packages as dependencies, which means that when you deploy a packaged Windows App SDK application, the framework is automatically deployed if missing, but the other components aren't. However, these packages are included inside the framework and, as such, can be automatically deployed by using the DeploymentManager API, which belongs to the Microsoft.Windows.ApplicationModel.WindowsAppRuntime namespace. Thanks to this API, you can check whether one or more of the components are missing on the system and install them if necessary. This is an example implementation of the OnLaunched() method of a Windows App SDK application, which is executed when the application starts:

protected override void OnLaunched
  (Microsoft.UI.Xaml.LaunchActivatedEventArgs args)
{
    var status = DeploymentManager.GetStatus();
    if (status.Status == 
      DeploymentStatus.PackageInstallRequired)
    {
        DeploymentManager.Initialize();
    }
    m_window = new MainWindow();
    m_window.Activate();
}

Thanks to the GetStatus() method, we can detect the status of the various components on the system. If one or more of them is missing (which is represented by the PackageInstallRequired value of the DeploymentStatus enumerator), we can call the Initialize() method to perform the deployment.

Unpackaged apps

For unpackaged apps, Microsoft provides an installer called WindowsAppRuntimeInstall.exe, which automatically detects the CPU architecture of a system (x86, x64, or ARM64) and installs system-wide the MSIX packages that compose the runtime – framework, main, and DDLM.

The installer also supports a --quiet parameter, which enables a silent installation with no user interaction and output messages. All the technologies and tools to create setup programs (or even just a PowerShell script) support the possibility of launching an executable as part of the installation, so it's easy to configure your installer to silently launch the WindowsAppRuntimeInstall.exe executable before or after the deployment of the main application, and before the whole installation process is completed.

Compared to a packaged application, you won't need to use the deployment APIs here, since the WindowsAppSDKInstall tool will take care of installing all the required packages on the system.

Upgrading the Windows App SDK runtime

The Windows App SDK runtime will continue to evolve over time, and as such, it's important for a developer to understand how future updates will be managed.

Updates can be delivered in two ways:

• If the machine has access to Microsoft Store, they will be automatically downloaded and installed.
• If the machine doesn't have access to Microsoft Store, it will be up to the application to include a newer version of the Windows App SDK runtime installer.

To control the way updates will be installed, the Windows App SDK has adopted the Semantic Versioning rules. By reading the official website (https://semver.org/), we learn that the version number is defined by three numbers, MAJOR.MINOR.PATCH, which stand for the following:

• MAJOR is incremented when you make incompatible API changes.
• MINOR is incremented when you add new functionality but with backward compatibility.
• PATCH is increased when you make bug fixes that are backward-compatible.

The runtime installed on a machine will be automatically updated only if the MINOR or the PATCH revision changes. If a new release increases the MAJOR number, instead, it will be installed side by side with the existing ones. This makes sure that newer versions of the runtime that might include breaking changes won't replace the existing ones, causing your applications to stop working properly.

Thanks to the DDLM component of the runtime, Windows will keep the old instance of the runtime installed as long as there's at least one running application that is using it. Once the application is closed, the previous version of the runtime will be uninstalled, and at the next relaunch, the app will start using the updated version.

Now that we understand how to manage the Windows App SDK dependency in our application, we're ready to start creating our first application.