New UWP support in .NET 9.0

[idg10]

I'm now looking at the preview .NET 9.0-on-UWP support currently in preview, I wanted to pull out a discussion from #2177 (reply in thread) into its own thread.

There are two issues:

1. Does this new tooling help us at all with the historical problem that the build tools basically have no support for UWP?
2. Do we add new support specifically for this new kind of application (UWP on .NET 9+)?

Unfortunately, it looks like the answer to 1 is: no. The big problem we have is that the main System.Reactive package includes a uap10.0.18362 TFM, and the .NET SDK does not support building for that TFM. UWP uses old-style projects (the kind we had before .NET Core was a thing). You can't simply include uap10.0.18362 in the <TargetFrameworks> because the .NET SDK doesn't know how to build for that target.

Currently, we use the MSBuild.Sdk.Extras project to enable us to use this TFM. However, that is no longer maintained. We have a solution for this in the branch that would update the project to use the .NET 9.0 SDK. (Essentially, we do some of the same things that MSBuild.Sdk.Extras does, enabling us to drop that dependency.) I've not yet merged that because I was hoping that maybe the new UWP support would provide a better alternative.

But as far as I can tell, there is not and never will be built-in support for specifying a uap10.0 TFM in a modern-style .NET project. We basically need to use all the hacks on that branch to move forward; the new UWP support in the .NET 9.0 SDK appears not to help us at all.

If anyone knows better, please chip in!

So this leaves the question of whether to add direct support for the new style of UWP app, in which you can use the modern .NET runtime, and not the weird old special version of .NET that UWP has used up until now.

@Sergio0694 initially wrote in another discussion:

This sounds like the perfect occasion to also add .NET 9 support for the UWP flavor of System.Reactive (see the announcement). Would this be something you'd accept as a contribution? Without this, there would be no way for UWP apps to continue using System.Reactive when moving to .NET 9 (eg. that applies to us too in the Microsoft Store app) . I'd love to help with this🙂

My current view on this is that this would belong in a completely separate NuGet package. About the worst thing we could do at this point is add support for yet another UI framework into System.Reactive. Since UWP on .NET 9 is a new thing, there's no binary backwards compatibility constraint here. So we could do this, but right now the tooling still seems to be in preview—you need to install the VS 2022 preview. So I suspect it will be .NET 10.0 before this is properly in place.

But before we get to that, there's the question of what actually happens if you try to use the current version of Rx.NET on this kind of project. Unfortunately, this new UWP preview feature appears to be broken in .NET 10.0 preview 4/VS 17.4.3 preview 0. (The title in that issue mentions MAUI, but the same bug also afflicts UWP.) So I can't actually try it at all at this point.

However, looking at the project.assets.json you get after adding Rx to a newly-created .NET-9/UWP app, it looks like it resolves to this:

"lib/net6.0-windows10.0.19041/System.Reactive.dll"

This suggests that this new kind of UWP app is going to be the latest victim of the same problem that drove Avalonia to abandon Rx. (You get an implicit dependency on WPF and Windows Forms even though you're using a completely different UI framework.) However, hopefully whatever we eventually do to fix that will work for UWP.

The next observation, then, is that since UWP on .NET 9.0 seems to present a Windows.UI.Core.Dispatcher, the existing ObserveOn overload in Rx 6's CoreDispatcherObservable is already available to this new kind of UWP app. Likewise, CoreDispatcherScheduler is available in this net6.0-windows10.0.19041 target of Rx.

As far as I can tell, everything we offer for UWP in the uap10.0.18362 is also present in the net6.0-windows10.0.19041.

So my question for @Sergio0694 (and anyone else interested in Rx on this new form of UWP) is: what UWP support would we provide that isn't already available today in the net6.0-windows10.0.19041 TFM?

[Sergio0694]

"currently in preview"

It's been GA and fully supported for over two months now (since Visual Studio 17.13), the blog post is a bit outdated 🙂

"UWP uses old-style projects"

To clarify, that only applies to legacy UWP apps. UWP .NET 9 apps use the normal .NET SDK and net9.0-windows10.0.XXXX.0 as TFM.

"not the weird old special version of .NET that UWP has used up until now"

I probably wouldn't recommend adding support for legacy UWP now, if you didn't already support it before.

"the worst thing we could do at this point is add support for yet another UI framework into System.Reactive"

You shouldn't have added any other UI frameworks to the same NuGet package either, as it's an endless source of issues. In the Microsoft Store I ended up having to crack the System.Reactive package open and manually reference just the net6.0 .dll, as just referencing the package was otherwise pulling in WinForms and WPF references as well. The official recommendation would be to have one separate NuGet package per UI framework. You fundamentally cannot rely on the TFM to disambiguate what UI framework one is using.

"the same bug also afflicts UWP"

That was an unrelated issue with the .NET SDK or something, and yeah it was affecting everyone. Should be fixed in .NET 10 Preview 5.

"UWP app is going to be the latest victim of the same problem that drove Avalonia to abandon Rx"

Unfortunately, yes. See the hack I had to do for the Microsoft Store as well, for the same reason.

"everything we offer for UWP in the uap10.0.18362 is also present in the net6.0-windows10.0.19041."

The API surface should be identical between the two, as far as "UWP APIs" go.

"what UWP support would we provide that isn't already available today in the net6.0-windows10.0.19041 TFM?"

Ideally:

• A way to reference the package without pulling in WinForms and WPF, and without needing hacks
• All the convenience helpers for UWP specifically (eg. the ObserveOnCoreDispatcher etc.)

Love seeing some interest here by the way, this is great! 😄

[idg10]

It's been GA and fully supported for over two months now (since Visual Studio 17.13), the blog post is a bit outdated

Huh. So I tried to install it on my non-preview VS install, and it didn't show up as an option in the installer. I had to go to my preview VM to see it. That's why I was under the impression that it was still in preview. Must be something busted on my machine...

I probably wouldn't recommend adding support for legacy UWP now, if you didn't already support it before.

I can't express how much I would like legacy UWP not already to be baked into the main System.Reactive component. (Even more so than all the other UI frameworks that are in there.) I would dearly love to cut it out completely.

But we've had support in there for years, so unfortunately v.next of System.Reactive will also have to offer it even if we mark it as deprecated and tell people to use some other library.

You shouldn't have added any other UI frameworks to the same NuGet package either

I didn't! It was like that when we took over. I've just been trying to work out how to fix that mess we inherited, so I'm painfully awre of what a bad idea that was.

A way to reference the package without pulling in WinForms and WPF, and without needing hacks

Yes - once we decide on how we're going to back out the aspect of the 'great unification' that led to all the UI stuff going into System.Reactive in the first place (without breaking everything for everyone in the process, which is the tricky part), and that will entail creating separate UI-specific packages.

So I think fixing the great over-unification by separating out the UI framework support will probably do what you want.

[Sergio0694]

"So I tried to install it on my non-preview VS install, and it didn't show up as an option in the installer."

To clarify, there's no top level "UWP workload" anymore. You'll get the UWP tooling if you select the "WinUI development workload", and then go to the additional components tab, and select "Universal Windows Platform Tools". That will include all the new stuff (and templates). Make sure to also check the 10.0.26100.0 SDK, as that's the one that bundles the updated XAML compiler for UWP .NET 9 apps 🙂

"I didn't! It was like that when we took over."

To clarify I didn't mean you specifically, I meant [generic you, whoever originally setup the repo] 😄

"So I think fixing the great over-unification by separating out the UI framework support will probably do what you want."

Yup, sounds like it!