Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Where does .NET 5 fit? #17

Closed
lukemcdo opened this issue May 19, 2020 · 17 comments
Closed

Question: Where does .NET 5 fit? #17

lukemcdo opened this issue May 19, 2020 · 17 comments
Assignees

Comments

@lukemcdo
Copy link

Question: Where does .NET 5 fit?

UWP has been on life support for a few years, with developers admitting that .NET Native, the UWP compiler, is on life support and will not get substantial feature upgrades. Meanwhile, .NET Core 3.1 and .NET 5 are the stated future of .NET.

While not every UWP app is a .NET app, many are. I'd like to start using .NET Core 3.1 features in apps that can run on Xbox, Windows, and Windows 10X.

I've recently read about the 2004 Hosted App release. Will expanded Win32 API access allow for a UWP .NET Core 3.1? And will Microsoft ship a host package for .NET Core 3.1 / 5 / 6, or would I be expected to ship the host package separately? If Microsoft ships it, what will the dependency management story be for version dependencies?

@AdamBraden
Copy link

Can you let us know more about what features you'd like to be able to use on other devices such as Xbox and 10X?

With WinUI3 you now have uwp XAML running in .NET5 - the first step enables this on desktop. To get on other devices such as Xbox, Hololens, or 10X there is more tooling work to be done to support the developer experience.

My question to you is, what is the developer experience you'd expect when you use an api on a given device that doesn't support all apis, such as Xbox? For example, if some part of System.Net.* isn't supported? What would you expect as the developers responsibility, and how much of the tooling experience should support you?

Regarding Hosted App Model - this was introduced as a way for an 'app' to run under a different identity and host additional content - largely to support Edge and PWAs, so that Twitter PWA is a separate app apart from Edge from the Windows perspective. That doesn't really fit with .NET Core/.NET5 which is a runtime framework. I think what you want is essentially for net5 to add a framework package, so your apps can use it without the need for it to be part of your redist - framework packages get installed/serviced from the store or an enterprise location. Or did you have an specific reason for .NET5 to be part of the Hosted App Model?

@lukemcdo
Copy link
Author

Windows 10X, from what developers have been told, prefers MSIX containers and "native containers" to Win32 containers. On 10X, a .NET 5 app is a Win32 app, or an MSIX app if we choose to redistribute .NET with it. Neither of these is ideal. I want a small app, as UWP apps are, but with newer technologies (.NET Core 3.1+) and UWP isolation, install, uninstall, and update experience.

Isn't Edge essentially a runtime framework from Windows' perspective, too? I would like to see .NET 3.1 and 5.0 added as additional options.

@lukemcdo
Copy link
Author

For reference, the Hosted App blog post detail is here. It demonstrates a host app for Python, and a hosted app composed of Python code. This should be possible for .NET, and Microsoft should provide the host apps to allow for a common dependency for developers to use.

@petroemil
Copy link

petroemil commented May 20, 2020

It would be nice to get some clarity on the UWP/.NET Native front. All the announcements were about making UWP tech available to Win32 apps, but not a word about the future of actual UWP apps (the kind that can natively run on Xbox, HoloLens, 10X, Hub, etc.).

Currently UWP runtime is based on .NET Core 2.2, have access to C# features up to 7.3 and we must compile the apps using .NET Native. We are already missing out on a number of features from the .NET Core world, like the new csproj format (that even WinForms and WPF received), or innovations and improvements in .NET Core 3.0 / 3.1 and C# 8... not to mention the upcoming .NET 5 and C# 9.

So how things will look like with the arrival of .NET 5 for "real UWP apps"?

@Kade-N
Copy link

Kade-N commented May 20, 2020

It's not exactly clear what this all means for UWP.

From what I'm understanding, it sounds like this is basically a replacement for UWP. Instead of developing a "UWP app", the new idea is to instead create a .NET 5 (or C++ or React) app, and then get Reunion components (such as WinUI, UWP APIs) to bring all the UWP features, into that .NET 5 app.

With WinUI3 you now have uwp XAML running in .NET5 - the first step enables this on desktop. To get on other devices such as Xbox, Hololens, or 10X there is more tooling work to be done to support the developer experience.

If I'm understanding this correctly, the path forward on desktop is to create a .NET 5 app using WinUI3? And this will eventually be enabled for other platforms, such 10X, Xbox, WMR/Hololens, thus becoming a proper replacement for UWP?

It all feels a bit vague... I feel like I'm reading too much into this, or missing something. Would be nice to have a good explanation of what Project Reunion is, and what it is not.

Right now, it's way too hard to figure out the most modern (i.e. actively developed and supported) approach to developing for Windows. I'm a student who wants to learn Windows development, but there's no clear starting point. There's so much talk about .NET 5, but almost nothing about "proper" UWP, which is stuck on a old version of .NET Core, despite being the newest (and supposedly most modern) way to make Windows apps.

@petroemil
Copy link

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?

@lukemcdo
Copy link
Author

The above points make a ton of sense, but honestly I don't have even that big of a need for the UWP app model. My position is this: I want to an app / apps using the latest Microsoft technologies written in C# using the correct app model for Windows 10X at launch date.

That means either UWP or another form of MSIX.

If Reunion won't be ready by Windows 10X launch, I would like some way for my .NET 3.1/5 app to be packaged in an MSIX and depend on .NET 3.1/5. Whether that's Hosted App model, or just a redistributable dependency like VCLib, I don't really care.

If this above method is just a stopgap until Reunion hosting .NET becomes a thing, that would be absolutely fine. I don't care if I have to port it again.

I just don't want to bundle a 50 MB runtime with any/every app I want to release for Windows 10X.

@petroemil
Copy link

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.

@lukemcdo
Copy link
Author

Really sounds like the .NET team has no interest in supporting Windows 10X then. The .NET story on Windows 10X could be completed in a number of ways:

  • Enable .NET 5 to run on Project Reunion
  • Provide and support a .NET 5 MSIX that projects can depend against
  • Update .NET Native to support new features
  • Support CoreRT on UWP with WinUI 3

If none of these items are complete, there will be no way to use the latest .NET technology with the latest Windows technology. Redistributing .NET 5 with every application is a nonstarter -- I have no interest in publishing updates with each runtime version security patch.

It sounds like Reunion enabling .NET 5 or not isn't the decision of the project -- where should I redirect my feedback?

@jonwis
Copy link
Member

jonwis commented May 23, 2020

It sounds like Reunion enabling .NET 5 or not isn't the decision of the project -- where should I redirect my feedback?

Please file issues about .NET and the support you need in their GitHub repo ... We intend for Project Reunion to be usable by .NET applications through the C#/WinRT projection, but Project Reunion is additive functionality to any existing application, not an application model in itself. (At least not yet.)

@sjb-sjb
Copy link

sjb-sjb commented Sep 21, 2020

Net/net, if you are currently developing in UWP then you should migrate to WinUI, specifically WinUI3. Do I understand it correctly?

@michael-hawker
Copy link

@sjb-sjb if you're a UWP dev today, you should stay on UWP until WinUI 3 UWP has everything you need. Main target for WinUI 3 developers currently is Win32 developers looking to use the modern UX stack.

@sjb-sjb
Copy link

sjb-sjb commented Dec 15, 2020

@michael-hawker, problem with that is the lack of NET 5 in UWP. There are too many things enabled by NET 5 (like C# 9 and Source Generators) to just do nothing for a few years until Microsoft finally brings NET 5 to UWP.

@sjb-sjb
Copy link

sjb-sjb commented Jan 8, 2021

Recognizing that this issue is closed but I thought I'd provide an update on the idea of migrating from UWP back to WinUI 3 Desktop with NET 5. My comments refer to a brief experiment, not a full port. The C#9 and .NET 5 part of it is great, with full nullability checking and a bit of extra support such as the SystemSounds class. There were a few complexities in the app startup, namely Desktop apps have a different lifecycle. In addition there is no CoreDispatcher (or more exactly, you can get a reference to a CoreDispatcher but it won't work properly) which means you have to implement CoreDispatcher.RunAsync using a DispatcherQueue. There are also currently some important gaps such as the UWP FilePicker classes are not implemented and the custom title bar does not work yet.

The main problem I've hit at the moment is really terrible performance, like, almost a second to move from one field to another on a page. I haven't tried any profiling to figure out what is causing this, so hopefully it is not major. Still, it is something that was not an issue at all in UWP.

EDIT: maybe the performance is related to this killer issue with DependencyProperty being slow in WInUI 3 ?

@HppZ
Copy link

HppZ commented Mar 30, 2021

@mevey why close this issue?

@pubtom
Copy link

pubtom commented 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

@dgellow
Copy link

dgellow commented Sep 11, 2024

Great news: https://devblogs.microsoft.com/ifdef-windows/preview-uwp-support-for-dotnet-9-native-aot/

We’re introducing the initial preview UWP (Universal Windows Platform) support for .NET 9, providing a path for existing UWP developers to modernize their apps with the latest .NET and Native AOT.

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests