Building a Roadmap for Windows Development

If you’re a developer that builds apps using .NET for Windows you’ll be familiar with Microsoft’s attempts to deliver a better developer story. Unfortunately this usually involves learning a new, typically under-baked, technology that in theory will make it easy to deliver better apps for Windows. Whether this was the jump from WinForms to WPF or WPF to Win8/UWP each time a new platform was introduced, the developer ecosystem fragmented and there were fewer developers building using the latest technology. In this post, and future posts, we’re going to discuss the WinUI and Project Reunion projects and how these aim to address this problem by unifying the Windows developer ecosystem.

Firstly, here’s a couple of links to the roadmaps for WinUI and Project Reunion:

• ProjectReunion Roadmap – microsoft/ProjectReunion (github.com)
• WinUI Roadmap – microsoft/microsoft-ui-xaml (github.com)

Future Windows Developer

Let’s start this discussion with a bit of a vision on what a Windows app of the future would be. For the purpose of this discussion I’m going to stick with .NET but of course there should be something similar available for native developers. Any examples will be given in C# but again there should be equivalent for F#, VB.NET etc

Given the direction that WinUI and Project Reunion are taking, you can imagine that in a year or so, when you go to start a new project there will be a set of new project templates in Visual Studio. One of these will be for a “Windows Application (.NET / C#)”, which will create a single project that can immediately be run from with in Visual Studio. For those who like the CLI you should also be able to run “dotnet new windows-app” and then “dotnet build -t:run” or similar to build and run the app.

What is this “Windows Application” that’s been created?

• WinUI – The UI layer/framework is WinUI3.0, making XAML the first class UI layout language and fully supporting both Binding and x:Bind to enable MVVM style applications. At this point, WinUI is no longer a standalone “thing” it’s just the Microsoft.UI namespace that’s part of the Windows Application platform.
• .NET – The runtime will be .NET 5 or 6 depending on release. The Windows Application components will be versioned in sync with dotnet, including marking versions as LTS.
• Windows App Container– The application will run as a regular windows application, meaning that it runs in the context of the current user (similar to a WinForms or WPF executable today). It can also be elevated to run as an Administrator (eg right-click, “run as Administrator”). However, via the project properties, the developer can opt-in to the Windows App Container, meaning that the application runs as Low trust and has to request permissions to access specific features (much like UWP today).
• Identity – The application doesn’t get an identity (i.e. no appxmanifest or packaging project). This limits the use of some of the WinRT APIs that rely on the application having an identity (for example ApplicationData requires the application to have a identity). However, again via the project properties, the developer can opt-in to having an identity – this will actually generate, if one doesn’t exist, an appxmanifest which allows the identity information to be specified. If the application is deployed via a package, the installation of the package will establish the identity. Alternatively if the application is deployed unpackaged, on first execution the application will register for identity (see Sparse Packaging)
• Packaging – The application doesn’t have, or require, a separate packaging project, nor does it get packaged as part of build and run (by default). This is similar to a WinForms/WPF application today. However, the developer can opt to run the application as if it were packaged via the run dropdown box in Visual Studio. The choice regarding packaging is made as part of the deployment process – to build and release standalone (i.e. not packaged), you can simply build with the Release configuration and then xcopy deploy the application; to build a package (for deployment to Store and/or enterprise deployment) you can publish the application (eg dotnet publish). The publish workflow provides options for packaging but also allows for Click-Once style deployment.
• App Life Cycle – The application has access to a rich application life cycle model, similar in many regards to the app life cycle that UWP has today. This is always available, irrespective of identity, packaging or any other configurable options. The lifecycle will cause the application to suspend/resume to optimise battery, allow for activation in a variety of scenarios and allows for managed background operation. Various parts of the lifecycle can be disabled, for example for applications that need to always be running or want to self-manage their lifecycle.
• Notifications – Similar to App Life Cycle, the application can access the notification system to send and receive (be notified) notifications.
• Windowing – The application has full support for being able to create and manage multiple windows.
• APIs – The application can access both WinRT and Win32 APIs
• Devices – Much like UWP of today, the application will be able to run on any Windows 10 device: Desktop, Hololens, Xbox, Surface Hub etc
• Compatibility – Existing WinForms, WPF and UWP applications can leverage parts of the new Windows Application platform using a technology similar to XAML Islands where UI components can be embedded. Other non-UI components, such as notifications, can be enabled by referencing the Windows Application platform and calling the appropriate APIs.

Let this sink in, and I’ll be back in the next post to start to tease out how we get to this and how it aligns (or doesn’t align) with the current WinUI/Reunion roadmaps.