Understanding the intersection of Reunion, UWP, and .NET 6

[mandalorianbob]

Hello all!

I've currently got an ongoing project that requires UWP, and is published in the Windows Store.

Now I know that .NET 5 has no story for UWP or the Windows Store.

However, now that .NET 6 is launching into Preview, I am eagerly awaiting the story for upgrading. Is Project Reunion going to be the vector upgrading to .NET 6? Or is that more on the .NET team?

I'm pretty confused by this, as so far nobody seems to be talking about it.

To summarize: I want a UWP app that is going to be put into the Windows Store to be able to be upgraded. Is that going to be feasible in .NET 6 via Reunion? Or at all?

[rgwood]

I’d love to hear more about this from the Reunion and WinUI teams, but my understanding is that there are no official plans/timelines yet (please correct me if I’m wrong). This has been a top ask from the UWP community - being stuck on .NET Native and an old .NET version is not a good situation.

However, WinUI 3 is in preview for the Win32 app model and the plan is for an early version of that to be released soon. And CsWinRt already lets you call WinRT APIs from .NET 5/6.

Between the two of those it should be possible to get most of the way there; it’s enough to let us develop apps that use WinUI and WinRT APIs, even if they don’t run in an AppContainer like UWP.

[mandalorianbob]

I've not seen that writeup! Thank you very much, I think this is really helpful. I'll take this to my team and see what we can do. (Seems like we could easily make a little library to shim in support.)

As for moving, I suspect there's a lot of bumps in that road. I'd have to put in the research, but some things off the top of my head:

• We make games, so we can't really be inside a Win32 chrome if that's an issue. And we need to be able to go full screen easily.
• I've had a lot of issues with the store over the past few years, and the idea of suddenly changing the packaging on an existing app just sounds like something that wouldn't be supported, haha. Maybe that would change by time we get around to it.
• We have Xbox Live SDK integration, which, afaik, comes in two flavors: C++ and C# UWP

Again, dunno if any of these are real issues, cuz I'd have to put research into them. To be honest, my leadership would see this as very high risk with not nearly enough reward, since it pretty much just makes my life easier haha.

But at any rate, thanks for the links, I think those'll be super helpful.

[Arlodotexe]

The larger question about UWP as-is running on NET5/6 instead of NETNative is something we are discussing [...]

That's concerning. Sounds like UWP support isn't landing in time for the next .NET6 LTS milestone, which means LTS customers are stuck on NETNative for another 3 years. Did I get that right?

This concerns me greatly, as someone who creates UWP apps for a living. I've spent a lot of time trying to figure out what the overarching plan is for us UWP devs, but the more I look, the more it seems like there is no plan.

I just want a straight answer to what's happening and where we're going.

[Sergio0694]

Just wanted to chime in as another fellow UWP dev regarding one of the main issues with .NET Native for us devs.
It's not just about C# 9 support, given that many features can mostly work on UWP as well (thanks for linking my blog post!).
The main issue with .NET Native (for me) is just that the runtime/BCL is 3 years old at this point and just out of date.
It's not just about C# verison, but actual runtime features and available APIs.

To name some:

• Can't target any library over .NET Standard 2.0.
• No built-in types for pretty much anything (no Span<T>, no Index, no Range, etc.). You need NuGet packages for all of them, and some are just not available anyway. Even when there are...
• ...The BCL has no support for them. There's little you can do with System.Memory if then not a single API in the entire BCL exposes overloads based on Span<T>/Memory<T> APIs, so you're forced to fallback to arrays anyway or write hacks to avoid performance loss.
• Absolutely no nullability annotations anywhere in the BCL, as the BCL used on UWP predates them. No built-in attributes either, so even just to use them in your own code you need to manually define them one by one (which is clunky).
• Some things are just broken, eg. .NET Native will just explode if you try to have a function pointer being used as a function parameter or return type. Because of this, packages such as TerraFX.Interop.Windows just fail to build completely on .NET Native.
• Absolutely no support for tons of newer APIs such as intrinsics and whatnot. This applies both to high-performance scenarios as well as geral quality of life improvements due to all the new APIs being added to the BCL in the last few years.

My issue is not with .NET Native per se, it's just that I find it unsustainable at this point to be stuck on .NET Standard 2.0.

Like @Arlodotexe said, many of us UWP devs are wondering when we'll finally be able to use .NET 6 on UWP.
And by that we don't mean to just rewrite our apps as a packaged WinUI 3 apps - we'd like a "proper" UWP app that just runs on exactly the same platforms as it does today (Desktop, Xbox, HoloLens, Hub, W10X, etc.), but using .NET 6 (so CoreCLR) instead of .NET Native. I perfectly understand how this is a complex issue with lots of moving parts, and that the team probably has other things (such as the support for Win32 apps that was mentioned) higher up in the priority list. But I just wish the communication was clearer on this front - I'd take a negative but definitive response over this uncertainty any day. It's been over a year now where all of UWP devs are just constantly waiting for an official announcement regarding this that has just never come so far 😢

Thank you for your time!

[lukeblevins]

If there is no future plan for UWP, we'd prefer you'd say so.

It's becoming increasingly apparent to me that there is a communication disconnect between what is now shipping decoupled from the platform and what's still tied to it. I understand that Windows is a proprietary product, but why must everything that touches it be guarded like a trade secret?

Others have mentioned above how they've been essentially punished for adopting the latest and greatest app model. Say I wrote a UWP app with the expectation that the API surface would grow and the platform would mature over time to cover scenarios requiring deeper shell integration. Right about now, I'm starting to look for an escape route from the sinking ship that is the inflexible, tightly-coupled app model of yesterday.

Except, Project Reunion isn't providing one for us outside of re-writing our apps to be a packaged WinUI Desktop solution.

Here is a pragmatic set of deliverables to give developers who invested in UWP projects more flexibility:

• Publicly announce that the way forward for new Windows apps is packaged WinUI Desktop
• Bring the WinUI Window concept to all device families including HoloLens, 10X, and Xbox
• Provide an automated tool to detect UWP-specific constructs and recommend WinUI-compatible replacements (i.e. replacing GetForCurrentView())
• Decouple AppContainer from UWP and allow developers to specify their trust level

[ghost]

• Decouple AppContainer from UWP and allow developers to specify their trust level

irony is the very moment a UWP app slips of the ground of Low IL trust level, it essentially confines it to be a desktop only app, thus breaking the main selling point('opt in to run Universally') of this "particular app model' in the first place.

the ability of running both win32 apps(win32,console,wpf,winform) , UWP apps in AppContainer will be a wise decision. such statement/sort of promise was made here 200#issuecomment.

nickrandolph perfectly described here :
491#issuecomment

Reunion should be able developers enabling features, not contorting their app to fit into some set of pre-defined packaging models. For example:

• As a developer if I want to be able to start with an unpackaged app that builds and runs without any need for packaging.
• I might later decide that my application needs an Identity (so it can use notifications, appdata etc) - to enable this I should be able to go to the Identity tab of the Project Properties, check Identity box and then add any additional information required for Identity.
• I might decide later that I want to take advantage of improved security model offered by the Windows App Container. Again, Project Properties, select Security tab and check the "Run in Windows App Container" box (there might be other properties on this tab relating to trust level etc).
• To make my application awesome I also want to take advantage of the modern app lifecycle (i.e. the uwp app lifecycle). For this all I need to do is override the appropriate lifecycle methods/events. Whatever OS level registrations that need to happen should be automatically done for me.

I'm not clear on all the nuances that I've properly overlooked but I do see that the current proposal/spec in no way clears up the confusion that exists regarding desktop v uwp v packaging v sparse packaging etc.

end of the day the UWP ship had sunk long ago, just the formalisation is overdue.

[vitordelucca]

UWP .NET 5 already works! But only o Xbox I believe. Didn't worked on 10x (probably because it generates a WinExe).

You can check a sample yourself

https://github.com/stevenbrix/WinUI3-Net5-Sample