Dotnet: UWP Roadmap, please?

[petroemil]

Build 2020 is now behind us and we heard exciting news about .NET 5 and Project Reunion, but not much about UWP.

It's great that UWP tech is being made available for Win32 apps through Project Reunion, but there are still absolutely valid reasons to build "true UWP" apps that can run on new types of devices like Xbox, HoloLens, Surface Hub, IoT or even Windows 10X.

As of now, .NET UWP apps still

• Based on .NET Core 2.1
• Only support libraries up to .NET Standard 2.0
• Only support C# up to version 7.3
• Use the old .csproj format

What are the plans to align UWP .NET with the latest .NET, so we can also benefit from the latest framework/language features?

What are the plans for .NET Native? Is it being abandoned? Are UWP apps going back to run on CoreCLR, or will there be something coming to replace .NET Native (CoreRT, maybe)?

I'll copy some of the responses that I collected in a thread in the Project Reunion repo that are trying to answer these questions - but in my opinion failing to do so.

I went around to other channels to try to find answers to this questions and I think I found it on the WinUI Discord channel, answered by @ryandemopoulos - hope he won't mind the quote

Sergio UI Bold Yesterday at 11:09 AM
Hey Ryan Demopoulos - I think my question got buried yesterday so I'll try again now

1) Just to clarify/confirm: for current UWP devs that need/want .NET 5 when it comes out (as well as WinUI 3 of course), the only upgrade path possible then is to (at least temporarily) completely drop the UWP app model, switch to WinUI 3 Desktop (since the codebase should mostly remain the same anyway), and then just hope the UWP target will be added for .NET 5 in the future, to eventually be able to move back into the good old UWP container/app model?

2) According to this chart for W10X then, WinUI 3 Desktop will not in fact be able to run with the native containers, right? I mean, UWP will remain the only option to use them, even though it won't support .NET 5 at least for a while?

3) Last question, just a curiosity. In yesterday's session you said that WinUI 3 is exclusive for .NET 5 and requires it, though the preview does in fact run on .NET Native as well. Is that just because it still lacks some features which will be breaking changes on .NET Native once added, or was that a choice to drop .NET Native made to ease the maintenance efforts, and/or because .NET Native won't be open sources too?

Ryan Demopoulos Yesterday at 2:19 PM
Hey Sergio, thanks for re-raising; yes I did miss these. I'll be brief since my next session starts soon, but here are quick answers:

1) What you wrote is mostly correct--if you have a strong need for .NET 5, then the only option for some time will be to use WinUI 3 in a desktop app. There is still some uncertainty here even on our end--a lot of it surrounds how quickly the reunion story unfolds, since Reunion will definitely support the latest .NET. It could be that there is a period in 2021 where UWP apps continue to use .NET Native, but then there is a great pathway to Reunion that supports .NET 5 (or, maybe .NET 6 by then), and people can just switch to that--so there would be a window of time where what you wrote is true. Plans aren't firm here--they're still being figured out, and I'd love your feedback on it.

2) That's correct; it's another one of the advantages of writing a UWP app. What I wrote above in 1) shows how it can be advantageous to be a desktop app, and here shows an example of where it can be advantageous to be a UWP app. Reunion is going to try and level the playing field so all apps have the unioned advantages of both models, but for a time there will be differences (just due to the reality of where we are today)

3) Um, ... I don't believe I said that? WinUI 3 is not exclusive for .NET 5 (for example, MAUI will also work with .NET 5), and WinUI 3 definitely won't require .NET 5 or even .NET at all. Probably around half of the ~80 or so companies we've reached out to early about WinUI write pure C++ apps; we think the MFC and C++ crowd will be a big factor in early WinUI adoption. No .NET needed; only optional! One last thing though: we're not planning to invest in two .NET runtimes. .NET Native will not be getting much in the way of new features, and .NET 5, 6, etc... will be the future of .NET.

So I think the key takeaway for the original question is this:

It could be that there is a period in 2021 where UWP apps continue to use .NET Native, but then there is a great pathway to Reunion that supports .NET 5 (or, maybe .NET 6 by then), and people can just switch to that.

For me - personally - it's still a bit of an open question if in the meantime UWP / .NET Native would get any update or is it being put on life support in its current state (.NET Core 2.1 + C# 7.3) until we can just directly switch to .NET 5 or maybe even 6?

And another bit of information from the Build session "The Journey to One.NET" at 1:24:37

What about UWP?

A lot of customers, as we ship .NET Core 3 especially, asked us about: "What about UWP? When is UWP coming to .NET Core?" And the answer is, there's no plan to do that, and that's because the Windows team is introducing something called WinUI. And WinUI is the next iteration of UWP. [...] So if you are a UWP developer, I'd say stay where you're at today, and then watch this WinUI project, as a great place to move your UWP apps when it's available and ready.

So the guidance is to stay put, keep using UWP as-is and it will get better _sometime later_. But I'd really like to get some specifics on this latter part, When and how will it change, what's the roadmap for .NET UWP apps?

[lukemcdo]

The "sometime later" bit is especially concerning -- where's the modern .NET development platform for Windows 10X?

[Sergio0694]

Regarding question 3), which was just a misunderstanding, see this follow up:

Ok @ryandemopoulos I went back and rewatched that part of the first WinUI session (to clarify my 3rd question in the pinned message), I got confused and it was actually quoting @marb2000, who said:

"WinUI is going to use only exclusively .NET 5, so .NET Framework is not going to be supported, and also .NET Core 3 neither as well. So only .NET 5."

But I guess he was just referring to WinUI 3 Desktop, and not WinUI 3 + UWP, which is in fact already supported with .NET Native. Sorry for the confusion on my part, all clear now then!

Also, note that you can absolutely use C# 8 on UWP!
I wish this was documented in more places, but anyway, just add this to your .csproj:

<LangVersion>8.0</LangVersion>

Place this under the first <PropertyGroup>. Note that .NET Native doesn't have _runtime_ support for C# 8, but you can still use all the features that are mostly just syntactic sugar (most of them anyway).

In practice (listing from the C# 8 features list):

• ✅ Readonly members
• ⛔ Default interface methods
• ✅ Pattern matching improvements (and related features)
• ✅ Using declarations
• ✅ Static local functions
• ✅ Disposable ref structs
• ✅ Nullable reference types (*)
  
  
  
  • NOTE: adding <Nullable>enable</Nullable> in the .csproj won't work. You'll need to manually add #nullable enable at the top of each .cs file. Other than that, the code analysis works just fine (but remember that the BCL itself is not annotated on UWP).
  
  
• ✅ Asynchronous streams (*)
  
  
  
  • NOTE: you'll need to install the Microsoft.Bcl.AsyncEnumerables NuGet package
  
  
• ✅ Asynchronous disposable
• ⛔ Indices and ranges
• ✅ Null-coalescing assignment
• ✅ Unmanaged constructed types
• ✅ Stackalloc in nested expressions
• ✅ Improved verbatim string interpolation

I mean, not a bad situation in general 😄

As for UWP on .NET 5, my understanding is that there's ongoing talk to discuss the roadmap there, so hopefully we'll hear more on this in the near future! As for .NET Native instead, it's still being updated with bug fixes and support for (at least some) future C# 9 features (eg. function pointers, as hinted at by @MichalStrehovsky in this tweet), but from what I know there are no plans to develop it further. In fact, you'll see back in the original .NET 5 announcement post that they made a list of all the shortcomings of having a full AOT solution (difficult to handle generics and reflection, can only use a baseline feature set for intrinsics, etc.), not to mention that .NET Native is a whole separate runtime than .NET Core, which causes all sorts of issues on its own (eg. different behavior and bugs only popping up in Release).

It is my understanding that, while AOT plans for UWP on .NET 5 are still very much work in progress, things are moving more towards a hybrid solution (eg. .NET R2R + tiered compilation).
Take all this with a grain of salt though, I'm sure either Michal or someone else from the .NET/WinUI team will be able to hop in and provide more info (and more accurate info too) 😊

[lukemcdo]

Honestly as long as there's a VS UWP-like template with .NET 5, WinRT lifecycle integration, WinUI 3, and easy MSIX publishing? That'd be fine. Getting .NET 5 into AppContainer at a later date would be best of course, especially for Xbox/Hololens.

I opened an issue in the installer project for .NET Core, but obviously the lifecycle integration would take more work. Is there any way for a non-UWP app to be lifecycle-aware? Or will we need to wait for .NET 5 in AppContainer to get lifecycle support?

[HppZ]

any update?