Repository navigation
UWP Roadmap, please? #1209
Description
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 Ryan Demopoulos (@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
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?
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?
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:
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.
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)
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?
Activity
lukemcdo commentedon May 31, 2020
The "sometime later" bit is especially concerning -- where's the modern .NET development platform for Windows 10X?
Sergio0694 commentedon Jun 2, 2020
Regarding question 3), which was just a misunderstanding, see this follow up:
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: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):
<Nullable>enable</Nullable>in the.csprojwon't work. You'll need to manually add#nullable enableat the top of each.csfile. Other than that, the code analysis works just fine (but remember that the BCL itself is not annotated on UWP).Microsoft.Bcl.AsyncEnumerablesNuGet packageI 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 Michal Strehovský (@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 commentedon Jun 5, 2020
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 commentedon Mar 18, 2021
any update?
vishvanathan-k commentedon Jun 28, 2021
Can anyone from UWP/.NET/Windows give us updates on this please
lukemcdo commentedon Jun 28, 2021
It's clearly done -- GDK for Xbox, WinUI double down, 10X cancelled in favor of Windows 11, and 0 HoloLens news means the only point of UWP over WinUI is the lack of framework packaging for .NET 5/6 so far and the lack of Xbox support.
Kade-N commentedon Jun 28, 2021
As far as I can tell, for the Win11 inbox apps, they are using UWP with .NET/C# and WinUI 2.6 XAML. No WinUI 3, no win32, no webview/electron. UWPs may be replacing some apps that were previously web-based.
Seems like it is the same current .NET (old core/native) and not .NET 5 or 6. No word on if/when they'll update it.
It's not an official announcement by any means, but if you want to follow what MS is currently doing for their own inbox apps, stick with "classic" UWP, they seem to be keeping it around as the default choice, despite not updating .NET in it.
https://twitter.com/RudyHuyn/status/1408176059019710464
I don't want to read into this too much, since it's just one dev, that probably wasn't alluding to anything... but I can't help but notice "UWP currently uses the "weird dotnet core"" and wonder if they do indeed plan to update it in the future. I feel like if they were going to kill UWP, they wouldn't have all these newly overhauled apps still using it.
vishvanathan-k commentedon Jun 29, 2021
My question , if UWP was gonna be killed , when shouldn't MSFT have replaced UWP apps in Windows 11 , right ? but instead many are coming to UWP.
lukemcdo commentedon Jun 29, 2021
MS will likely begin replacing them when they have either an AOT solution or framework packaging solution that works well with the stable version of WinUI 3 to ensure they don't need to provide a system-wide runtime that could accidentally become as embedded as .NET Framework was.
vishvanathan-k commentedon Jun 29, 2021
Yeah but as you all know Windows app sdk's (or Project reunion's) main aim was to push win32/wpf/winforms users to use UWP like UI ,if not 'THE UWP UI', and also encourage them to use Sandboxes which UWP apps use, if there app can support it. With an app running UWP UI and UWP appcycles , sandbox, apis along with win32 backend. how long does it takes to move apps to full UWP with no win32. the only problem with UWP ,as of now is, it is not updated regularly . Luke (@lukemcdo) afair , NativeAOT in .net runtimelabs is just a fork of .net native evolved for cross platform .I hink it will nice if microsoft removes some restriction for Sandbox like unlimited access for files execpt in some system owned folders like \windows ,\System , and program files. you can't use UWP for some purposes but we can use it for most purposes
Kade-N commentedon Jul 3, 2021
From the same microsoft dev as my last comment, when asked about whether UWP was dead
https://twitter.com/RudyHuyn/status/1410473505401966596
Wish we could get a copy of that roadmap, but it definitely sounds like one does exist internally...
vishvanathan-k commentedon Jul 3, 2021
Yeah , But the Biggest Doubt is what they are doing ??, While some teams are using/moving towards UWPs like the new windows 11 store and are pretty well updating it . But also,WPF are also used, while some have gone too far with Hybrid models , UWP UI and WPF Core/Backend like Windows terminal.WPF is only used where you need unlimited file access or to access other apps without any restriction like Power Automate Desktop
pubtom commentedon Nov 30, 2021
If you need .NET>5 in UWP please give a vote on this: https://developercommunity.visualstudio.com/t/Add-NET-678-support-to-UWP/1596483
Sergio0694 commentedon Nov 30, 2021
I feel like it might help to clarify things a bit here in case there's any confusion on terminology.
It seems to me people keep using the term "UWP" to refer to two related but very different things:
CoreWindow, AppContainer, MSIX, etc.)These two are not the same thing at all, and depending on which one you meant, the result will be different:
CoreWindow, AppContainer, MSIX, etc., that is perfectly doable, just not officially supported, and there's no tooling for that. But consider this, you can literally have a UWP Flutter app, or a UWP Rust app if you wanted. One of the main points of the UWP platform was to be language agnostic, so this is technically doable, in theory, by design.Realistically speaking, at this point it would seem more reasonable to me to just ask for WinUI 3 to eventually get support for running under
CoreWindowand with the same feature set with respect to app lifecycle management etc. that UWP XAML/C# apps had (and many of these are planned already). You can already have WinUI 3 apps packaged with MSIX, so we're already halfway there. All I'm saying is, asking for ".NET 5+ for UWP" without context is very ambiguous and doesn't mean much if you don't specify what you're referring to. It would certainly help this proposal to be more specific 😊dongle-the-gadget commentedon Dec 10, 2021
C#/WinRT has replaced the native WinRT interop with .NET 5+, meaning that even if UWP would be able to use .NET 5+, there will be much more overhead. That's pretty much the same situation as WinUI 3 right now.