search

microsoft / dotnet

This repo is the official home of .NET on GitHub. It's a great starting point to find many .NET OSS projects from Microsoft and the community, including many that are part of the .NET Foundation.
https://devblogs.microsoft.com/dotnet/
MIT License
14.27k stars 2.21k forks source link

UWP Roadmap, please? #1209

Open petroemil opened 4 years ago

petroemil commented 4 years ago

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

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 commented 4 years ago

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

Sergio0694 commented 4 years ago

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):

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 commented 4 years ago

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 commented 3 years ago

any update?

vishvanathan-k commented 3 years ago

Can anyone from UWP/.NET/Windows give us updates on this please

lukemcdo commented 3 years ago

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 commented 3 years ago

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

The previous Store was half HTML, the new one is fully UWP XAML! C#/XAML UWP currently uses the "weird dotnet core" :) But all our services are .Net 5 No, our team also owns the big majority of the inbox apps ;)

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 . @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 commented 3 years ago

From the same microsoft dev as my last comment, when asked about whether UWP was dead

https://twitter.com/RudyHuyn/status/1410473505401966596

It's not ;)

I don't even understand how you can still debate about that... You know that app teams and system/framework teams are very close, work together, collaborate a lot and build roadmaps together?

If you really want to know if something is dead, observe closely what the company owning the technology does with it, follow some employees and stop listening to rumors :)

Wish we could get a copy of that roadmap, but it definitely sounds like one does exist internally...

vishvanathan-k commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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:

These two are not the same thing at all, and depending on which one you meant, the result will be different:

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 CoreWindow and 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 commented 2 years ago

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.