What is Actually the Universal Windows Platform and what is WinUI, MSIX, and Project Reunion / Windows App SDK?
This morning I got a wonderful message from a very smart and great person who watched my latest Pluralsight course, Fundamentals of Building .NET Desktop Applications. The course explains the .NET UI frameworks Windows Forms, WPF, UWP, WinUI (including Uno platform), and .NET MAUI in an overview and shows how to build your first .NET Desktop Apps for Windows with WinUI, WPF, and Windows Forms. The structure of the course is like this:
- Knowing the UI frameworks for .NET Desktop Apps
- Creating Your First WinUI App
- Building Your First WPF App
- Writing Your First Windows Forms App
The message that I got this morning said the following:
You seemed to be using UWP to refer to two different things, a “framework” and an “app model”
From a highly respected developer
So, it was confusing that I used the term Universal Windows Platform (UWP) to refer not only to a UI framework, but also to an app model. That’s correct, I did this, and I can understand the confusion very well, because I’ve been there too. I tried to explain things as clean as possible, and with as less ballast for new .NET desktop developers as possible.
The goal of the “Knowing the UI frameworks for .NET Desktop Apps” course module was and is that developers know why WinUI 2.x and WinUI 3.x were introduced and how WinUI is related to UWP. And after watching the course they should be able to build a WinUI app and also make the decision whether they use the UWP app model or the Win32 (Desktop) app model for their application. The goal was not meant to do a deep dive into the Universal Windows Platform, as this is way more than just WinUI.
But now, we’re already using some terms like app model before we have clarified the big picture. Let’s dive deeper into the topic in this blog post, so that we all, you and I, have a clear understanding of what UWP actually is. In addition, let’s also look a bit at other parts like MSIX and Project Reunion (which is called Windows App SDK since 24 June 2021, when Windows 11 was announced) that are also related to this whole UWP and WinUI story.
Before we start, I want to make one point very clear: The multi-dimensional use of the term UWP is a problem, it is something many developers struggle with, beginners and professionals with years of experience. I’ve seen developers talking to each other (sometimes I was one of them), and everyone used the term UWP to refer to a different thing.
This problem exists, because the term UWP is actually used for many different things. So, once for all, let’s get this sorted out my friends. 😎
First, I want to tell you from my experience the most important things that come to my mind when I hear the term UWP.
What is the Universal Windows Platform?
The Universal Windows Platform was introduced with Windows 10. It is available on all devices that run Windows 10 and Windows 11: PC, HoloLens, Xbox, Surface Hub, or IoT devices. In Visual Studio there is a project template called “Blank App (Universal Windows)” that allows you to build a UWP application that will run on any of these devices. You can build the application with .NET/C# or with C++. To create user interfaces, you use the Extensible Application Markup Language (XAML), which is an XML-based language that was introduced originally with the Windows Presentation Foundation (WPF) in the year 2006. WPF is another UI framework, and UWP uses many concepts that you find in WPF, like XAML, data binding, styles etc. That means that a WPF developer gets up to speed with UWP quite fast, and vice versa. But WPF is not a UI framework that C++ developers can use, for WPF you have to develop with .NET/C#, C++ is not supported there. That means C++ developers were left behind. With UWP, C++ developers are again part of the game.
An important part of UWP applications is that they run in a sandbox, system access is restricted. This makes a lot of sense when you think about the fact that you can distribute UWP apps via the Microsoft Store. The UWP app has to declare capabilities to be able to use specific resources of your system. You might know this from mobile applications, when you can see messages like “This app wants to access your pictures, your documents and your contacts”. A UWP app also has to declare these capabilities, so that they will work for you as a developer and that a user can see what an app wants to do. Another thing about UWP apps is that they are packaged in the form of an .appx file (which is based on .zip format), which makes it possible to install and uninstall UWP apps in a very clean way on your Windows 10/11 machine. Another important part of UWP apps is the activation and lifecycle management. Win32 apps keep running when the user minimizes them or switches to another app. That’s not good for devices that run on battery like tablets and many other portable devices. UWP apps solve this problem with an activation and lifecycle management. A UWP app can get suspended when it’s in the background, so that the system can save resources and battery.
But now you see already that UWP apps have some different features, like XAML, packaging, sandbox, lifecycle management etc. So, UWP seems to be more than just a UI framework. What is actually UWP?
The Universal Windows Platform is not just one thing, that’s why the term is used in multiple dimensions, and that’s why it can get confusing. Here is a list that comes directly out of my brain, so that you can see what I think what UWP actually is, without guarantee of completeness:
- UWP app – this is an app that you’ve built with C# or C++, and the app uses all the other points mentioned in this list. There’s a project template for this app in Visual Studio called “Blank App (Universal Windows)” (Available only if you’ve installed the Univeral Windows Platform development workload with Visual Studio).
- UWP XAML framework – this is the part of Windows 10/11 that you use to build your UWP apps with, it contains XAML and the visual layer that is necessary to render your app, including user input functionality.
- UWP XAML controls – the controls that you use in your UWP apps, they’re also part of Windows 10/11.
- WinRT – the Windows Runtime is a modern Windows API that uses .NET metadata to describe its contents. It’s part of Windows 10/11 and exists on your PC beside the classic Win32 API of Windows.
- UWP packaging – UWP apps are installed as a package (.appx file, based on .zip), which makes it possible to install and also uninstall them in a very clean way, without leaving some registry clutter or folders left on your machine.
- UWP app model – UWP apps run in a sandbox. They have to declare capabilities to get access to different system resources, like for example your internet connection. To support this restricted sandbox, Windows has to host your application in a special way, and that hosting model is also often referred to as the UWP app model. The other traditional hosting model on Windows is the Win32 hosting model, which is also referred to as the desktop hosting model. Also part of the UWP app model is the activation and lifecycle management, which is especially important for portable devices that run on battery.
Side note: We look here at UWP from the perspective of a XAML and C# developer. Using the UWP XAML framework might be the most common way for .NET developers to create a UWP application, but it is not the only way. The UWP XAML framework layer sits on top of a visual layer that sits itself on top of DirectX to render your UI. Instead of using XAML and C#, you could for example also use DirectX directly, or you could use HTML and JavaScript with React Native for Windows.
Now, when developers talk about UWP, they can refer to any of these points in that list. Important to know is that all these points are available on any Windows 10/11 device, like PC, HoloLens, Xbox, Surface Hub, or IoT devices. That is because all these points are a part of the Windows 10/11 core. And exactly that causes a dependency problem.
The Dependency Problem with the UWP XAML Controls
The UWP XAML controls are part of Windows. This is a strong dependency to the operating system. It means that the users of your UWP application have to use the latest Windows version, so that you can use the latest UWP XAML controls and control features. Microsoft has broken up this dependency by providing the UWP XAML controls as a NuGet package that you can reference from your UWP application. That NuGet package is called WinUI 2.x. WinUI stands for Windows UI library. This means the dependency between your app and the operating system regarding UWP XAML controls is removed. Now your UWP app can depend on the WinUI 2.x NuGet package, and you and your users can enjoy the latest UWP XAML controls without having to update your computers to the latest Windows version.
This means, you know now what happened with point 3 of the list above:
1. UWP app
2. UWP XAML framework
3. UWP XAML controls => part of WinUI 2.x NuGet package
4. WinRT
5. UWP packaging
6. UWP app model
The UWP XAML controls are still part of Windows for existing applications, but they were copied to the WinUI 2.x NuGet package, and new features and new development are done in that WinUI 2.x NuGet package that you can reference from your UWP application.
Side note: That all XAML controls are copied to the WinUI 2.x NuGet package is a simplification in this blog post. The reality is a bit more complex. Only WinUI 3.0 that is described in the next section includes all the XAML controls and also the XAML framework. To dive deeper into WinUI 2.x, scroll down to the comments and read the one from Marcel Alexander Wagner (a C# dev and WinUI contributor).
Now let’s look at the next dependency, the UWP XAML framework
The Dependency Problem with the UWP XAML Framework
The UWP XAML framework is part of Windows since Windows 10, and that is actually the same kind of dependency between your UWP app and the Windows operating system like we had it in the previous section with the controls. It means that you can only use the latest framework features if you run the latest Windows version. Microsoft has also decoupled this dependency from Windows, and it is part of WinUI 3.0. WinUI 3.0 is a NuGet package that contains point 2 and 3 from our list:
1. UWP app
2. UWP XAML framework => part of WinUI 3.0 NuGet package
3. UWP XAML controls => part of WinUI 3.0 NuGet package
4. WinRT
5. UWP packaging
6. UWP app model
Now, moving also the UWP XAML framework to WinUI makes WinUI 3.0 a full-blown UI framework like WPF or Windows Forms. You find the repository of WinUI on GitHub: https://github.com/microsoft/microsoft-ui-xaml. Check out also the issues there, they contain announcements for WinUI community calls, which are live sessions on youtube with the WinUI team and the community that you can join. The WinUI community calls are hold on a monthly basis.
Now, back to the WinUI 3.0 NuGet package. This NuGet package is not meant to be used in a classic UWP app that you create in Visual Studio with the “Blank App (Universal WIndows)” project template, because these apps point to the original version of the UWP XAML framework that is part of Windows, and not to the decoupled version of the UWP XAML framework that comes with the WinUI 3.0 NuGet package.
To use the WinUI 3.0 NuGet package in your application, you need to install the WinUI 3.0 project templates in Visual Studio. Learn how to do this by reading the docs. After installing the project templates, you have two project templates to create a WinUI 3.0 project in Visual Studio:
- Blank App (WinUI in UWP)
- Blank App, Packaged (WinUI in Desktop) <= Win32
The following screenshot shows these options in the “Create a new project” dialog of Visual Studio 2019.
Both options create an application that references the WinUI 3.0 NuGet package, which means you get the UWP XAML framework and the UWP XAML controls to build your application. The difference is in the underlying app model, or app hosting model. So, let’s look at this in the next section.
What about the App Model?
Let’s talk about point 6 of my original list, the UWP app model:
6. UWP app model – UWP apps run in a sandbox. They have to declare capabilities to get access to different system resources, like for example your internet connection. To support this restricted sandbox, Windows has to host your application in a special way, and that hosting model is also often referred to as the UWP app model. The other traditional hosting model on Windows is the Win32 hosting model, which is also referred to as the desktop hosting model. Also part of the UWP app model is the activation and lifecycle management, which is especially important for portable devices that run on battery.
With the WinUI project templates installed, you can choose if you want to create a WinUI in UWP app, or a WinUI in Desktop app. The first option gives you a traditional UWP app that references the WinUI 3.0 NuGet package. It means that your app runs in a sandbox and you can install it on different Windows devices, like PC, HoloLens, Xbox, Surface Hub, or IoT. The app also saves resources when it is in the background, which is important for portable devices that run on battery. The second option – WinUI in Desktop – creates a classic Win32 app that references the WinUI 3.0 NuGet package and that runs on your PC and that can do anything there like a WPF or Windows Forms app. This kind of app doesn’t have restricted system access like a sandboxed UWP application.
This means that you can use WinUI 3.0 to build an application with the UWP XAML framework and UWP XAML controls and you can choose between:
- .NET/C# and C++
- UWP and Win32 app model
The two app models clarify what happened to point 6 of our list
1. UWP app
2. UWP XAML framework => part of WinUI 3.0 NuGet package
3. UWP XAML controls => part of WinUI 3.0 NuGet package
4. WinRT
5. UWP packaging
6. UWP app model => part of Windows since version 10, available on all Windows devices, not only PC/Desktop. With WinUI 3.0, you can choose between this app model or the traditional Win32 app model
The Old and the New Way To Create a UWP app
The WinUI 3.0 project templates give you the option to use the UWP app model or the Win32 app model, as mentioned in the previous section. This means also that the existing Visual Studio project template “Blank App (Universal Windows)” is the old way to create a UWP app. Remember, that project template uses the UWP XAML framework built into Windows 10, it’s not possible to reference and use WinUI 3.0 there, but only WinUI 2.x. For new UWP apps, you should use the “WinUI in UWP” project template that creates a UWP application that uses the UWP XAML UI framework and UWP XAML controls from the WinUI 3.0 NuGet package. Now you also know what happened with point 1 of our list:
1. UWP app – for new apps, don’t use “Blank App (Universal Winows)” template, but “WinUI in UWP” template that creates a UWP app that references the WinUI 3.0 NuGet package.
2. UWP XAML framework => part of WinUI 3.0 NuGet package
3. UWP XAML controls => part of WinUI 3.0 NuGet package
4. WinRT
5. UWP packaging
6. UWP app model => part of Windows since version 10, available on all Windows devices, not only PC/Desktop. With WinUI 3.0, you can choose between this app model or the traditional Win32 app model
Next, let’s look at the packaging.
UWP Packaging for Clean Installations
UWP applications are packaged in a format that has the file extension .appx. That is a .zip based file format. Windows 10 knows how to install and uninstall these packaged applications. There’s no clutter left when you remove an UWP app.
The interesting part is that this packaging feature is actually built into Windows 10, and you can also use it to install and uninstall traditional Win32 apps, like WPF, Windows Forms or WinUI in Desktop apps. To do that, Visual Studio has a project template called “Windows Application Packaging Project”. This project can reference your Win32 project, and it creates a so-called MSIX package, which is the packaging format of Windows 10. The file that you get is an .msix file, and that file format is exactly the same file format as the .appx file of a traditional UWP app. This MSIX package allows you to distribute also classic Win32 applications like WPF or Windows Forms via the Microsoft Store, as they get installed and uninstalled in a super clean way, controlled by Windows 10.
When you create a WinUI in Desktop app that uses the Win32 hosting model, you automatically get such a package project that creates the MSIX package for you. That means, packaging is independent from the chosen app model. No matter if you use WinUI in UWP or WInUI in Desktop (Win32), you can always package your app to distribute it in a clean way. This means, we know what happened to point 5 of our list:
1. UWP app – for new apps, don’t use “Blank App (Universal Winows)” template, but “WinUI in UWP” template that creates a UWP app that references the WinUI 3.0 NuGet package.
2. UWP XAML framework => part of WinUI 3.0 NuGet package
3. UWP XAML controls => part of WinUI 3.0 NuGet package
4. WinRT
5. UWP packaging => part of Windows since versioon 10, based on MSIX format. Also Win32 applications can be packaged via MSIX to install/uninstall them in a clean way.
6. UWP app model => part of Windows since version 10, available on all Windows devices, not only PC/Desktop. With WinUI 3.0, you can choose between this app model or the traditional Win32 app model
Now, finally, let’s look at the WinRT.
The Windows Runtime (WinRT)
The Windows Runtime (WinRT) is the modern Windows API that is available on all Windows devices since Windows 10. Sometimes developers also refer to this one as the UWP API. The WinRT uses many concepts of .NET, like .NET metadata to describe it’s members, and also concepts like classes, properties, events etc. But it’s important to understand that the WinRT is a native part of Windows and written in C++. But the API is projected into other languages, so that you have the feeling that it is a native part of the language that you are using. For example, if you are using C#, you can use C#/WinRT which doesn’t feel different from using any other C# component or library.
Beside the WinRT, the older but still powerful Win32 API exists in Windows 10/11. And now the question is: Should the available APIs for your application depend on the app model (UWP or Win32) that you have chosen for your app? No, you should be able to get the best out of Windows, no matter if you have a UWP or a Win32 app. And exactly for this, Microsoft works on Project Reunion. On 24 June 2021, when Microsoft announced Windows 11, they renamed Project Reunion to Windows App SDK. That new name makes it actually more clear what it is, the name Project Reunion was anyway meant to be used only during development. The Windows App SDK unifies the Windows developer platform, so that you as a developer can build applications for any Windows 10/11 version and also for any device. Let me just quote from their GitHub readme:
Project Reunion/Windows App SDK makes it easier to build a great Windows app by providing a unified platform for new and existing Win32 and UWP apps. It will unify access to existing Win32 and UWP APIs and make them available decoupled from the OS, via tools like NuGet.
https://github.com/microsoft/WindowsAppSDK
Now, what does this mean regarding point 4, WinRT, of our list? It means that the modern WinRT API of Windows 10/11 is available for your applications, no matter if you build WinUI in UWP, WinUI in Desktop, WPF or Windows Forms:
1. UWP app – for new apps, don’t use “Blank App (Universal Winows)” template, but “WinUI in UWP” template that creates a UWP app that references the WinUI 3.0 NuGet package.
2. UWP XAML framework => part of WinUI 3.0 NuGet package
3. UWP XAML controls => part of WinUI 3.0 NuGet package
4. WinRT => part of Windows 10 and available for UWP and Win32 applications
5. UWP packaging => part of Windows 10, based on MSIX format. Also Win32 applications can be packaged via MSIX to install/uninstall them in a clean way.
6. UWP app model => part of Windows 10, available on all Windows 10 devices, not only PC/Desktop. With WinUI 3.0, you can choose between this app model or the traditional Win32 app model
Summary
Now you have seen that WinUI 3.0 is actually just a part of the UWP universe. WinUI 3.0 contains the UWP XAML framework and the UWP XAML controls. But UWP as such contains many more things, like the app model with the sandbox, the packaging functionality and the WinRT API. All these things are built into Windows since version 10.
The Windows App SDK (formerly known as Project Reunion) makes all of that available to Windows desktop developers, no matter which UI framework they are using.
WinUI 3.0 itself is actually a sub project of the Windows App SDK, because WinUI 3.0 allows you to build desktop apps with Win32, UWP, .NET/C# and also C++. It is your choice what you want to use. Also MSIX is a sub project of the Windows App SDK, as it allows you to package your application for Windows 10/11, no matter if you have created a WinUI in UWP, WinUI in Desktop, WPF or Windows Forms application.
Now, how do we answer the question: What is actually a UWP app?
There are developers who told me that they have created a UWP app for the Microsoft Store, but what they actually did was packaging a WPF app as MSIX. Is that a UWP app? They use UWP packaging functionality, but I wouldn’t call that a UWP app. For me, a UWP app is an application that runs on the UWP app model, in the sandbox. That’s it. Today you can build such an app with WinUI 3.0. If you need full system access and the sandbox is an issue, because you’re building for example a file explorer that can execute different commands, you can use WinUI in Desktop to get an app that uses the Win32 app model. All the existing UWP functionality of Windows like WinRT or packaging is always available for you, no matter if you go with the UWP or with the Win32 app model.
I hope this blog post has shed some light into the dark.
Please leave your thoughts and questions in the comments.
If you have a Pluralsight subscription, also check out the Fundamentals of Building .NET Desktop Applications course to learn more about the different UI frameworks for .NET desktop applications.
Thanks for reading,
Thomas
Comments (34)
Excelente publicación y obviamente me aclara el panorama, soy desarrollador de Windows Forms de toda la vida y me gustaría actualizarme, para las personas que no sabemos inglés sería excelente que hicieras un curso en español ya q muchos estamos en un dilema con .net 5, gracias por compartir tus conocimientos. Saludos desde Chimbote, Perú.
Gracias Alexander, me alegro de que te haya gustado el artículo. Muchos saludos desde Alemania, Thomas
Publishing your WinUi App in the Microsoft Store is a must have App for everyone Worldwide 24/7
Great article, however the UWP XAML Controls section is a bit simplified. While it is true that new UWP XAML Controls are being developed in WinUI 2, old controls have not been copied. WinUI 2 contains new controls for the UWP XAML framework that have been built on top of the existing UWP XAML Controls (Windows.UI.Xaml.Controls namespace). In addition to new controls (that ship as part of the Microsoft.UI.Xaml.Controls namespace), WinUI 2 also ships new control styles for existing UWP XAML Controls. The code behind of these controls however still remains in UWP XAML. Bugs and APIs that have been fixed/introduced in newer Windows versions will still be only available on newer Windows versions. While WinUI 2 lives in it’s own repository, it is still depending on UWP XAML Controls (that’s also why it’s sometimes referred to “UWP XAML + WinUI 2”) and allows you to use the newest controls and new style updates regardless of the OS version the app runs on. However existing UWP XAML Controls still behave the old way and might have updated control styles. but no new APIs or bug fixes.
Now WinUI 3 is a whole different story. With WinUI 3, ALL controls will be shipped as part of WinUI with no dependencies on UWP XAML Controls at all. WinUI 3 controls will behave the same on every machine, regardless of OS version or the UWP XAML Controls being available as all of the old UWP XAML Controls are now also in the WinUI 3 code base. That way, bug fixes, new APIs and visual updates can be used by apps regardless of the installed OS as WinUI 3 will ship the controls as part of the NuGet package. This also means though that you can’t use UWP XAML Controls (Windows.UI.Xaml.Controls namespace) in your WinUI 3 apps (Microsoft.UI.Xaml.*).
Thank you Marcel for these great insights. I’ve added a hint in the blog post, so that readers are aware of your fantastic comment here.
Great article.
Thanks
I’m trying to build a classic win32 desktop app (c++) with a WPF user interface built with NET Core 3.1. In the WPF user interface I use the UWP map control. All seems to work but there is something that sound strange. I opened an issue on github but no one give me an answer. Can you take a look to it https://github.com/windows-toolkit/Microsoft.Toolkit.Win32/issues/306#issuecomment-771186359
Thank you
Hi Ivan,
I looked at your issue on GitHub, but I don’t know what the problem is with that C++ application. Let’s wait a bit until someone pick’s it up.
Thank you Thomas
Thank you for the explanation. Is there a chance to do another post where you explain MAUI in the same way :)
This is a fantastic breakdown of UWP. The only part I would like to see expanded on is the section talking about the UWP app model which covers both the execution sandbox and the app lifecycle. These should be treated separately since you can have a WinUI Desktop app running in the Windows app container (i.e. the same sandbox a UWP app gets) but it doesn’t automatically get the application lifecycle events that a UWP app gets. It’s worth pointing to the work being done by Project Reunion to improve lifecycle support for Desktop apps.
Hi Nick,
thank you, happy to read that you like the blog post. :-)
I’m not sure if I understand the part that you would extend correctly. A WinUI in Desktop app does not run in a sandbox like a WinUI in UWP app, or like a traditional UWP app. It’s packaged with MSIX, but it is not running in a sandbox. You can for example scan the folders of the C: drive without any issues in a WinUI in Desktop app with this code:
var dirInf = new DirectoryInfo(@"C:\");var sb = new StringBuilder();
foreach (var item in dirInf.GetDirectories())
{
sb.AppendLine(item.Name);
}
var folders = sb.ToString();
In a WinUI in UWP app or in a traditional UWP app you would get an UnauthorizedAccessException when executing this code.
Best,
Thomas
Outstanding Post.
I was going through the official documentation for a couple of days to understand the WinUI. I had no clear idea until I finished this article.
I have taken a couple of your courses that gave me a jump start. You are a great tutor.
Thank you Umar, happy to read that you like this post. Have a wonderful weekend, Thomas
This is the best explanation that I have seen so far! It made the whole idea very clear to me. Diving into your course right away. Thanks.
Thank you Emmanuel, I’m happy to read that it made UWP clear to you. Hope you’ll enjoy the course. Thomas
Thank you Emmanuel, happy to hear this. Best, Thomas
While creating uwp app I tried using control channel trigger in background network communication but it failed.
When creating a uwp app, I would like to be able to create cct.
Super useful article! Thanks a lot for explaining this! UWP, WinUI and this whole mess finally makes sense!
Thanks Istvan, happy you like it. Thomas
Wonderful explanation! I’m watching your course on Pluralsight but I was confused with what WinUI was compared to UWP.
Microsoft it terrible at naming things which makes it very confusing but you did a great job of making it very clear.
Thank you Mark,
happy to read that you like this blog post. Which Pluralsight course are you watching?
Good lord man, thank you. I’m a WPF developer and noticed a high level of stress among my colleagues in the past few years. WPF is getting long in the tooth, but for many enterprise applications UWP just doesn’t have the access I need. So as soon as I started seeing chatter about WinUI 3 there was obvious curiosity, but good information hard to come by.
They just announced too much in a short window. XAML islands, Project Reunion, Maui, WinUI 2/3… it’s really hard to figure out what vine we should be getting ready to swing to as a desktop dev.
Thank you!
Easy: Qt, it works Windows, Linux, MacOS. Also it will still exist in 10 years, it’s actively being developed and you can use C++ with CMake, Python or C#. So you won’t have to worry what “framework” you’ll be using next year when the wind changes
Great blog post, Thomas! Congrats. Many thanks / Merci beaucoup. I will check out your Pluralsight course and also I have a question for you: I developed a Uno UWP app and the only (but big) problem is my development team leader is very frustrated because what he expects and requires is an unpackaged desktop app with only 1 .exe file ideally (or even a few files) that can fit on a USB stick to run the app on some Windows 10 PCs inside the organization (out of the Microsoft Store). So now, to face this challenge ASAP, is my only option to port this UWP app to either WinUI 3.x or WPF for .NET 5? (or Avalonia or even Project Reunion maybe)? In other words, can I build an unpackaged (without MSIX) WinUI 3.x app? Or, which seems much more unlikely, is there a way to simplify UWP / Windows 10 apps deployment: no certificate and no MSIX package? Many thanks in advance for your kind answer. Note: any Thomas’s blog reader having an answer to my question is very welcome to reply too. Thank you so much.
Hi Thierry, unpackaged WinUI 3 apps will be available with version 1.0 of Project Reunion that is expected to come out later this year. Project Reunion was renamed on June 24 to “Windows App SDK”. Right now, WPF is the way to go to get a normal .exe file.
Super Blogbeitrag. Endlich versteh ich die ganze Geschichte mit WinUI, Project Reunion, etc.. Ich hoffe es wird bald alles produktiv einsetzbar.
Danke Jan, das freut mich, dass der Blogbeitrag hilfreich war. LG Thomas
Can you clarify the situation of UWP app model and WinUI 3 after the recent announcement of the WinUI 3 vs. 2.x split.
Btw: I really like this article. Clarifies so many things. It helped me tremendous. One nitpick: What about the programming runtimes like .NET Native, JS/WinJS etc. Where is the sandbox (part of UWP app model is not it)?
Hi Thomas,
Thanks for this awesome POST regarding UWP and explained in details.
Really loved this post. Gives great insights for a beginner like me.
Hi Thomas ,
I have created an application in WIN-UI-3 and trying to get UWP life cycle hooks/events in win-ui-3. but unable to find any life cycle hooks/events in it.
1- actually I’m trying to create an activity monitoring application, something like hubstuff and I want to know if I’m on right path 2- Please suggest what should I do ?
this is my .csprod:
WinExe
net5.0-windows10.0.19041.0
10.0.17763.0
App3
app.manifest
x86;x64;arm64
win10-x86;win10-x64;win10-arm64
true
CA1416, $(NoWarn)
Thank you for the explanation. Is there a chance to do another post where you explain MAUI in the same way :)
Yes, there is a chance. :)
Wow, could Microsoft had made this any more confusing? Thank you so much for this summary! (Although I’m still a bit confused). There are just too many choices, and some are quite new (Win UI 3), and now they’ve added MAUI… and what about MFC? Is that ancient history nobody should touch?
What is the best framework choice for a C++ developer to create a Windows 10/11 desktop app today in June/2022?
And what about a portable multi platform app for Windows, Android, OSX, iOS, and Linux?