Last month I posted on Building a Roadmap for Windows Development, where I discussed some of the components that need to come together in a coherent manner for the Windows developer platform of the future. These included things like running in the Windows App Container and the app having an Identity. In this post I’ll discuss at a high level why it’s necessary to have a vision for the Windows developer platform.
The overall vision for the Windows developer platform has to be a combination of technical capability coupled with appropriate tooling. It has to be inclusive, providing a roadmap and a future direction for both existing and new developers (and projects/products). The vision also has to cover not only the Windows platform but also how the Windows developer platform will align with other cross platform, web and cloud development technologies.
Note: Through this post I refer to Project Reunion – there’s a lot of discussion going on about this name and if/how the name appears as part of the final packages. For now, I’ll refer to Project Reunion, but I do expect this naming to change.
Capability and Tooling
The first part of what needs to be included in the vision is around the raw capability of the Windows developer platform and the tooling that would be provided to assist developers building applications. This would typically manifest itself as some form of Windows SDK and/or Workloads in the Visual Studio installer.
Currently for a Windows developer the Visual Studio installer experience isn’t particularly intuitive – under the Desktop & Mobile section there’s .NET desktop, Universal Windows Platform, a couple of C++ options and Mobile development (which also incudes Windows). I typically install all the non-C++ options and then I go through the dozens of individual components where I can pick and choose which additional components I want.
A unified vision for the Windows platform should start with a single workload for developing for Windows. As we’ll discuss later, it may be relevant to have additional options that vary the individual components included in the workload based on the requirements around legacy technologies.
Moving on from the installer, the tooling for building for the Windows platform should be easy to access. Where a visual designer is available, the main page of the application should be displayed in the designer upon the creation of a new app. It goes without saying that intellisense should be available for XAML and C# editing.
When debugging an application, the default behaviour should be for Hot Reload to be enabled and that the Live Visual Tree and Live Properties tool windows are shown.
For UWP applications, the package manifest held a lot of information about the application, such as capabilities and details required for the application to be granted an identity. The reality is that these shouldn’t be independent, they should form part of the properties for the project and thus be available with the Properties window. As UWP features, such as app container, identity etc are added to desktop applications, they should be done in a way that it is easy for developers to enable/disable features, without resorting to hacking at the XML in the project file.
Inclusive Roadmap
As a Windows developer it feels that the ecosystem goes through a reset every 4-8 years. The following graph is one that’s been produced in order to promote WinUI 3 as a unification technology.
This diagram conveniently forgets that between WPF and UWP there was also Silverlight, Windows Phone 7, Windows Phone / Windows 8 development. These technologies have been deprecated and most applications have since been migrated either to some other web technology or pulled forward kicking and screaming to UWP. However, it can’t be underestimated the damage that this continual churn has caused the windows developer ecosystem.
The other reason that this diagram is misleading is that WinUI3 is only one of the first components of a much larger, and more ambitious, effort, which is Project Reunion. From this diagram it would appear that WinUI3 is another discrete UI platform and in some regards it is – the XAML is mostly the same as UWP but isn’t directly compatible with either WPF or UWP XAML. However, by consuming Project Reunion, a WinForm or WPF app will be able to leverage the equivalent of XAML Islands in order to host WinUI3 controls, or even entire Windows (Note that whilst this is on the WinUI roadmap, there’s no timeline for it yet).
Part of the challenge in coming up with a clear vision for the Windows developer platform is that the ecosystem has been fragmented so many times. Whatever the vision is, it needs to cater for developers coming from WinForms, WPF, UWP etc and provide a roadmap for them to not only learn the new pieces (WinUI, Reunion etc) but to be able to put them into practice in their existing apps.
The vision needs to accept that very few companies are in a position where they can simply rebuild their application in the latest framework. As such, there needs to be clear roadmaps and guides for how different technologies can migrate forward. This doesn’t mean that every technology, including every version of those technologies, is supported. It does mean that if developers want to leverage the new pieces, they can do so without having to break their existing applications.
Cross Platform, Web and Cloud
The latest piece that I feel is important to a strong vision for the Windows developer platform is that the vision recognises that Windows app development doesn’t exist in a bubble.
Often developers will be required to build cross platform application, not just for Windows. The vision for the Windows developer platform should reference compatible tools and strategies for building for Windows in parallel with other target platforms.
Developers are also often required to build for the web. Does the vision for the Windows developer platform allow developers to reuse their skills in any way?
Lastly, developers often have to consume APIs from one or more cloud services. In order for Window developer platform to be successful, there needs to be out of the box support for basic functionality such as authentication, logging, diagnostics, crash reporting etc. Making cloud services easy to consume will encourage developers to target the Windows platform.
What is the Vision for the Windows Developer Platform?
If only I knew!!! I’m not confident enough on where the various teams at Microsoft are working on to take a stab at what the vision would/could/does look like.
However, what is worth doing is to look at a few target developer scenarios (by no means exhaustive) and discuss how they might move forward.
Greenfield (New) Project/Product
In this scenario the developer would create a new Project Reunion application, which includes WinUI3. This application is essentially just a .NET 5 based application but it has access to features such as Identity, Lifecycle and Push Notifications, and can be configured to run in the Windows App Container.
Existing WinForms / WPF Applications
The long game for these application is to have them almost exclusively rebuilt in WinUI3. However, Microsoft has realised that it’s more important to light up some of the Windows platform features, that to force developers to redevelop the application. Using the equivalent of XAML Islands, components from WinUI3 can be integrated into existing and new Windows of the application.
Existing UWP Applications
Microsoft committed early in the development of WinUI3 that upgrading a UWP application to use WinUI3 would mostly be a simple change of namespaces. As WinUI3 nears completion, we’ll need to see whether this commitment is honoured, and if not, what other application changes will be required.
It’s also hard to imagine a world where the UWP project file doesn’t switch to being an SDK style project but this will require further investment to make this possible. If the UWP application is now an SDK style project, presumably referencing .NET 5, is it just a desktop application that happens to be running in a Windows App Container?
Summary
As you can see from this post, the Windows developer platform is undergoing some rationalisation at the moment. Things are a little confusing, particularly for developers new to building for Windows. However, there is a ray of light at the end of the tunnel that what’s coming will mean a better, more progressive, platform for every Windows developer.
Whilst I’m not able to provide a definitive vision for the Windows developer platform, by teasing out the important features in post like this one, hopefully Microsoft can use the feedback to provide a structured vision in the coming weeks.