Question: .NET 5 UWP apps are already possible, so when will official support arrive?

[Aminator]

Question: .NET 5 UWP apps are already possible, so when will official support arrive?

When it comes to .NET 5 support for UWP apps, we don't really have a clear answer yet to how that will look like and when it will come. UWP developers shouldn't have to be stuck on an old .NET version while Win32 developers are seemingly way ahead and can also use the new C#/WinRT language projection.

How to create a .NET 5 UWP app

What I found is that despite Microsoft telling us developers that creating UWP apps running on .NET 5 is not supported yet, it is actually quite easy to do today with minimal setup and it even works with WinUI 3. You can start off with the regular .NET 5 console app template and modify it from there. This process involves three steps: Modifying the project file, adding a package manifest file and generating a PRI file. Be sure to have the latest .NET 5 preview SDK and Visual Studio Preview installed. I have provided samples in this repository.

Project file

You need to add a few properties, NuGet packages and targets. I tried to make it as independent of Visual Studio and the Windows 10 SDK as possible.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <!--If this property is set to WinExe, the app will not spawn a console window.-->
    <OutputType>WinExe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <Nullable>enable</Nullable>
    <TargetPlatformVersion>10.0.19041.0</TargetPlatformVersion>
    <TargetPlatformMinVersion>10.0.18362.0</TargetPlatformMinVersion>
    <!--Platforms are only necessary for WinUI 3 and only x86 and x64 are supported at this time.-->
    <Platforms>AnyCPU;x86;x64;ARM;ARM64</Platforms>
    <!--The Main method needs to be defined manually to avoid an exception.-->
    <DefineConstants>$(DefineConstants);DISABLE_XAML_GENERATED_MAIN</DefineConstants>
  </PropertyGroup>

  <ItemGroup>
    <Content Include="AppxManifest.xml" CopyToOutputDirectory="PreserveNewest" />
    <Content Include="Assets\**" CopyToOutputDirectory="PreserveNewest" />
  </ItemGroup>

  <!--The C#/WinRT language projection and WinUI 3 is used in this project.-->
  <ItemGroup>
    <PackageReference Include="Microsoft.Windows.CsWinRT" Version="0.1.0-prerelease.200623.5" />
    <PackageReference Include="Microsoft.Windows.SDK.NET" Version="10.0.18362.3-preview" />
    <PackageReference Include="Microsoft.WinUI" Version="3.0.0-preview1.200515.3" />
  </ItemGroup>

  <!--Any XAML files that have a code-behind file need to be listed here.-->
  <ItemGroup>
    <Page Update="App.xaml">
      <Generator>MSBuild:Compile</Generator>
    </Page>
    <Page Update="MainPage.xaml">
      <Generator>MSBuild:Compile</Generator>
    </Page>
  </ItemGroup>
  
  <!--This target generates a resource file for your app based on the priconfig.xml file and the files in the output directory.-->
  <Target Name="MakePri" AfterTargets="Build">
    <Exec Command="&quot;$(MSBuildProgramFiles32)\Windows Kits\10\bin\$(TargetPlatformVersion)\x86\MakePri.exe&quot; new /pr $(OutputPath) /cf priconfig.xml /of $(OutputPath)resources.pri /o" />
  </Target>
  
  <!--The manifest needs to be registered with the OS and after doing this, your app will appear in the app list.-->
  <Target Name="RegisterManifest" AfterTargets="MakePri">
    <Exec Command="PowerShell Add-AppxPackage -Register $(OutputPath)AppxManifest.xml" />
  </Target>

</Project>

Package manifest

The package manifest named AppxManifest.xml is needed to register your app with the OS, but notice that it's not the regular Package.appxmanifest file you find in old UWP projects, which would generate the final AppxManifest.xml for you. If you use an existing one, be sure to remove the package dependency for UWP .NET Core and use the release version of VCLibs.

<Dependencies>
  <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.19041.0" />
  <PackageDependency Name="Microsoft.VCLibs.140.00" MinVersion="14.0.27810.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
</Dependencies>

For WinUI 3 you also need to add any types you use from it to your manifest. This also needs to be done for WinUI Desktop.

<Extension Category="windows.activatableClass.inProcessServer">
  <InProcessServer>
    <Path>Microsoft.UI.Xaml.Controls.dll</Path>
    <ActivatableClass ActivatableClassId="Microsoft.UI.Xaml.Controls.TreeView" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="Microsoft.UI.Xaml.Controls.TreeViewItem" ThreadingModel="both" />
  </InProcessServer>
</Extension>

Resources

It is necessary to have a file called resources.pri in your app for any assets, including XAML files, to be accessible by your app. This can be generated using MakePri.exe. It takes a configuration file called priconfig.xml as an input. You can create a new configuration file with the command makepri createconfig /cf priconfig.xml /dq en-US. Be sure to remove the following two tags if you want to only create a single resources.pri file.

<packaging>
  <autoResourcePackage qualifier="Language"/>
  <autoResourcePackage qualifier="Scale"/>
</packaging>

Entry point for WinUI 3

A custom entry point needs to be defined for WinUI 3 apps because the automatically generated one applies the STAThreadAttribute to the Main method, which causes a wrong thread exception.

public class Program
{
    private static void Main(string[] args)
    {
        ComWrappersSupport.InitializeComWrappers();

        Application.Start(p =>
        {
            DispatcherQueueSyncContext.SetForCurrentThread();
            new App();
        });
    }
}

Building and debugging

The project can be built either on the command line using dotnet build or in Visual Studio, though for WinUI 3 it currently needs to be done in Visual Studio. Do not start the app from Visual Studio, this would execute the .exe file directly and essentially be a Win32 launch. The app needs to be launched by clicking on the app list entry in the Start menu or the icon on the taskbar. A debugger can be attached from Visual Studio after the app has been started.

Issues

The biggest issues with this approach are:

• It requires more manual setup.
• The whole .NET runtime needs to be shipped with the app if it is self-contained.
• There is no AOT compilation.
• Launching an app of this type directly from Visual Studio is not supported.
• A generator for the package manifest is not included in the .NET SDK or a NuGet package.
• MakePri.exe is not included in the .NET SDK or a NuGet package.
• WinUI 3 depends on targets from Visual Studio.
• WinUI 3 generates a faulty entry point.

Conclusions

I have been using .NET 5 and WinUI 3 in my own UWP projects for a few weeks now and it has been working quite well and I was able to take advantage of new .NET APIs that I didn't have access to before. The main issues come from WinUI 3 still being in preview, so there are still many missing pieces, which is why I wouldn't recommend it for production use just yet.

Through this process I also came to understand what the main difference between a UWP and a Win32 app is and it all has to do with how the app is launched. It is the EntryPoint on the Application element in the package manifest that determines if it will be a UWP or a Win32 launch. For UWP it will be YourProject.App and for Win32 it will always be Windows.FullTrustApplication.

It is also unclear if this type of app will be accepted in the Microsoft Store, so I would like to know more information about that. The other question remaining is the one I stated at the beginning: Since it is possible to build UWP apps running on .NET 5 today, what is the holdup on supporting it officially? It would be great if Microsoft provided additional tooling to make the process easier for developers. I would like to see a rough timetable on when we can see the issues I mentioned resolved. Hopefully we can see it officially supported whenever WinUI 3 is ready for production, so that UWP developers that make the switch can also take advantage of .NET 5 immediately.

[ShankarBUS]

Does that work like a UWP app,

I mean have CoreWindow, support xbox & etc.

What you did sounds like how a packages win32 app work but hacked to look like a UWP app

[Aminator]

@ShankarBUS This method does create an actual UWP app and it's using CoreWindow. Just look at the repository I provided, which contains a project that just uses CoreApplication and the other uses the WinUI 3 Application.

[Pinox]

I'm so with you here, I wanted to move to .net standard 2.1 a long time ago in my cross platform solution where I want to use gRPC but this beautiful UWP beast is holding me back ;)) plse MS tag and bag this thing !!

[Felix-Dev]

When it comes to .NET 5 support for UWP apps, we don't really have a clear answer yet to how that will look like and when it will come. UWP developers shouldn't have to be stuck on an old .NET version while Win32 developers are seemingly way ahead and can also use the new C#/WinRT language projection.

Can't stress this enough. .NET 5 support for UWP has been the number 1 question from the UWP developer community for months now (see for example the recent 3-4 WinUI Community Calls). The messaging from the MS teams on this very important topic for UWP developers has been absolutely catastrophic:

First, while the .NET team in its initial .NET 5 introduction blog post mentioned UWP, it has been silent on this topic very much ever since. If you read the blog posts for the different .NET 5 previews...do you see any official comment on the UWP .NET 5 situation? Nope, not at all. It feels like the .NET team has no interest in this topic any longer. For example, see this issue where in May this year, the community explicitly asks for a UWP roadmap for .NET. Do you see any reply by the .NET team there? Did the .NET team assign anyone to this this issue? The answer is: NOPE. Apparently, the .NET team just doesn't care about UWP.

Secondly, in the absence of other MS teams to ask or give us answers, the UWP developer community turned to the WinUI team. Now, the WinUI team arguably is the wrong team to ask on this matter here so they get a pass for not knowing the exact status of .NET 5 on UWP. Yet, the answers we do receive month after month of constant asking are incredibly disappointing. Here they are:

• .NET 5 support for UWP could arrive with Project Reunion or it could not
• We don't know when support will arrive. You perhaps have to wait until the .NET 6 timeframe (which is more than an entire year away)

So, why are these answers we are getting time and time again really disappointing here? They tell me two things: MS doesn't know how .NET 5 support for UWP will arrive and it doesn't know when. The resulting optics paint a pretty bleak picture of the importance of UWP at MS. .NET 5 is one of the biggest stories for Windows developers out there and communication with the UWP community on this topic has been absolutely abysmal.

Lastly, the UWP developer community then went to Project Reunion to ask for clarification and details on the UWP on .NET 5 story. See this issue for example. A community member came - in that thread - to the following conclusion:

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

To which a Project Reunion team member at MS, @jonwis, replied with the following:

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

Remember the first point in my post? That the community went to the repo of the .NET team and asked for a ".NET roadmap for UWP"? Remember that that issue received zero care by the .NET team?

Remember the second point, where the WinUI team has been telling us that ".NET 5/6/... support might come via Project Reunion"?

What I am seeing here is this: No team at MS wants to be responsible for UWP on .NET 5:

The .NET team -> Absolute silence in both Preview blog posts and on their repo
The WinUI team -> Project Reunion might be used here to bring .NET 5 support to UWP
The Project Reunion team -> Ask the .NET team.

Is the state of the UWP really so pitiful internally at MS that more than a year after the intial introduction of .NET 5 the UWP developer community has zero clue at all how and when support for .NET 5 will arrive? Are we UWP developers that unimportant to MS that seemingly no one wants to step up, lead that project and have a respectful and constructive interaction with the community?

I will leave with this picture from the official .NET 5 introduction blog post:

It has been downhill ever since then for the UWP developer community....

[LeftTwixWand]

It seems to all available resources Microsoft spending to Project Reunion and MAUI. And UWP'll die in a few years.

[driver1998]

If it means we can build UWPs without Visual Studio and Windows SDK, that would be great news. Looks like it is basically there.

[olugt]

On the issue about UWP and .NET 5, I feel since UWP is basically a Windows-targeted solution, it would only make sense for it to evolve with Windows (currently Windows 10). So, since Windows 10 is still taking some shape (e.g. Start menu revamping, etc.), UWP may have to wait.

[saint4eva]

@olugt I think the revamping and Windows 10X are being done using UWP? At least the Windows and .NET teams should give the community a concrete answer. If they would not support it, let the community and the customers know.

@Aminator Thank you for this wonderful effort. All I am asking the Windows/ .NET teams is to give us a concrete response.

[Pinox]

@Felix-Dev , I'll add some more points that makes UWP future questionable.

MS announced the Winget package manager at build. So now we are going to have the MS Store + Winget which I assume has it's own "store" ( source packages).

So now we are going to have 2 "sources" for apps that makes no sense whatsoever except if there is a plan to create a new "source" that winget and Windows Store will feed from.

MS announced that the Ad platform on MS Store is ending.

The fact that UWP uses .net native for compilation and there is no .net native toolchain in .NET 5 that I'm aware of really brings UWP to it's end of life as we know it.

Perhaps there are plans next year to hop onto the AOT bandwagon that will give UWP a new direction therefor the lack of response from MS regarding this.

I just wish the leadership at MS can address this issue, because it's clear the individual teams are skirting this issue because they themselves probably also don't know.

As a developer that uses UWP this is important issue for me , because I have made an investment already in UWP and I don't want to write off that investment. If I need to go the win32 route to prolong my investment I will do that. To me the ideal solution at this moment looks like win32 with AOT as you can do so much more and you still have access to UWP contracts plus an added performance benefit of no sandbox.

So MS let there be a fallout in your announcement then at least we can all move forward.

@Aminator Thanks for your effort. You have shown more commitment and hope for UWP's future than MS themselves.

[ptorr-msft]

@Aminator on the original question re: Microsoft Store, you should run the WACK (appcertui.exe from the SDK) on your package locally and see if it gives any errors. If you are submitting a partial-trust package ("UWP" / AppContainer) then it will potentially fail due to unsupported API calls from the .NET Runtime. If you are submitting a full-trust package (Desktop Bridge / Centennial) then the API check is skipped.

Although you have the entire .NET Core runtime bundled with your app (which makes it larger and can increase the number of WACK failures), you can reduce the number of DLLs in your package quite significantly; it just takes a lot of trial and error to remove the ones you don't need.

[stevenbrix]

you can reduce the number of DLLs in your package quite significantly; it just takes a lot of trial and error to remove the ones you don't need.

You should be able to set PublishTrimmed in your .csproj and that will strip out the .net core assemblies that aren't used

[lukemcdo]

I added this issue thinking our only option would be .NET 5 in a desktop bridge MSIX. Operating from the UWP container is even more exciting since the upgrade path is incredibly clear. If we get Framework Packaging then there shouldn't even be a change in size for the end user (except for their first .NET 5 app).

I assume there isn't support for lifecycle functions in this, right? That'll need at least the C#/WinRT projections.

[pjmlp]

For me Project Reunion was the official statement of what was slowly started with XAML Islands and MSIX replacing APPX.

Basically the admission that WinRT was badly managed since the beggining, with incompatibile .NET variant and very constrained API, followed by the multiple reboots, Windows 8 WinRT with multiple projects, Windows 8.1 UAP with common logic , UWP, XAML Islands,...

So basically we are getting proper .NET, WinUI (now written in C++ to cater to MFC guys), and with Reunion it still isn't clear what is going to be.

What irks me is that for a while UWP looked like how .NET should have been from the get go (meaning .NET v1.0), and with C++/WinRT those of us that are forced for various reasons to use C++ alongside .NET have lost the nice Visual Studio tooling from C++/CX (apparently we have to wait that ISO C++23 adopts the missing features to improve C++/WinRT tooling story).

So with the past experiences of also having invested lost time into Silverlight and XNA, WPF looks like a more solid story for the time being really.

MS really needs to decide what message they want to send to the Windows development community.

[lukemcdo]

Message is pretty clear: "the no-appcontainer crowd from WPF days yelled louder, sorry guys"

[olugt]

On the issue about UWP and .NET 5, I feel since UWP is basically a Windows-targeted solution, it would only make sense for it to evolve with Windows (currently Windows 10). So, since Windows 10 is still taking some shape (e.g. Start menu revamping, etc.), UWP may have to wait.

I may have made a bit of oversight though. But it still seems to me that Microsoft is trying to not be distracted by UWP (because to me, the effect of any work done on UWP is only visible with a corresponding update to Windows 10) but to instead focus on Project Reunion (https://github.com/microsoft/ProjectReunion/blob/master/docs/README.md), which seems to be about bringing the best of UWP and others (e.g. WPF) together. But I bet it would be very much like UWP. Project Reunion seems to be what would make apps realise the best features and capabilities Windows 10X and its successors would offer, while making it easy for mostly all existing apps to easily come on board.

[jtorjo]

@Felix-Dev On man, I'm so with you here! Was just gonna write a post "How/when will .Net 5 / UWP / WinUI" come together".

I am soooo dissapointed by MS. They keep on saying that UWP is the future, but nothing truly happens. I have a 110K+ LOC UWP app, and working on it is harder and harder:

• Compile times suck.
• If you run into any "Async" issues, you're f***ed - no stack trace, nothing
• If you run into performance issues, most of the performance tools from MS suck big time. And to make matters worse, because of the "great" UWP sandbox, pretty much no other tools work. So we're at the mercy of MS. I investigated a memory issue a few days ago, the "Performance Profiler" gave me mostly "Unknown code" calls. I literally had to test by commenting out code and seeing what happens - back to stone age.

Can't stress this enough. .NET 5 support for UWP has been the number 1 question from the UWP developer community for months now (see for example the recent 3-4 WinUI Community Calls). The messaging from the MS teams on this very important topic for UWP developers has been absolutely catastrophic:

Agreed, more than 100%

First, while the .NET team in its initial .NET 5 introduction blog post mentioned UWP, it has been silent on this topic very much ever since. If you read the blog posts for the different .NET 5 previews...do you see any official comment on the UWP .NET 5 situation? Nope, not at all. It feels like the .NET team has no interest in this topic any longer. For example, see this issue where in May this year, the community explicitly asks for a UWP roadmap for .NET. Do you see any reply by the .NET team there? Did the .NET team assign anyone to this this issue? The answer is: NOPE. Apparently, the .NET team just doesn't care about UWP.

I feel exactly the same way. My thinking is that WinRT is soooo complicated behind the scenes, that NO ONE wants to deal with it. They just throw keep throwing the ball to someone else, hopefully it will at some point get fixed.

I've been asking for compile time improvements for ages - nothing happened. Seems they will start after fixing Hot Reload, but who knows if/when that will happen.

The File/Folder API is a bad joke - it's been known FOR YEARS. We're simply down to workarounds.

There's already support for Async Call Stack (so that if you have async calls, they will be remembered in the Call Stack after the async call returns). And yes, they don't work for UWP.

Everyone is using .net core 3.1, but UWP is back to 2.2 - I've been asking this in several places. When will UWP use .net core 3.1? No answer.

And you know this yourself - we've been asking for improvements in WinRT - has any of them actually been implemented?

Even now, if you look at the UWP controls, pretty much all of them has been developed with the "mobile first" in mind. Like, the scrollbar, by default is very small, and you have to hover it and then it'll show up. So, I want the scroll bar to be visible at all times - the fact that this can't happen with just a line of code (in fact, you can do it, with about 1000 lines of XAML), speaks volumes.

The list could go on...

It simply feels that even inside MS, everyone would just want WinRT to simply go away, but no one does anything about it (side note for MS : everyone would love for WinRT to go away).

[...]

• We don't know when support will arrive. You perhaps have to wait until the .NET 6 timeframe (which is more than an entire year away)

This is what I'm talking about. No one wants to deal with UWP / WinRT, and they just throw the ball from one team to the next.

(my take, once again, is that the culprit is WinRT, because UWP itself is awesome!)

So, why are these answers we are getting time and time again really disappointing here? They tell me two things: MS doesn't know how .NET 5 support for UWP will arrive and it doesn't know when. The resulting optics paint a pretty bleak picture of the importance of UWP at MS. .NET 5 is one of the biggest stories for Windows developers out there and communication with the UWP community on this topic has been absolutely abysmal.

I've been saying this again and again. It feels that MS is using us as guinea pigs, and whenever they feel like it, they may implement something.

They don't trust UWP (or more likely, WinRT) themselves. I've been asking: where is any UWP application developed from MS, that is decently complex (like, 50K+ LOC) ? I have yet to see one.

My app has 110K+ LOC, and it's a constant struggle to keep my sanity.

What I am seeing here is this: No team at MS wants to be responsible for UWP on .NET 5:

The .NET team -> Absolute silence in both Preview blog posts and on their repo
The WinUI team -> Project Reunion might be used here to bring .NET 5 support to UWP
The Project Reunion team -> Ask the .NET team.

Yes, it's beyond dissapointing.

Is the state of the UWP really so pitiful internally at MS that more than a year after the intial introduction of .NET 5 the UWP developer community has zero clue at all how and when support for .NET 5 will arrive? Are we UWP developers that unimportant to MS that seemingly no one wants to step up, lead that project and have a respectful and constructive interaction with the community?

Not only that, but basically, they keep ignoring the two groups of developers that develop UI apps:

• UWP - we already know that
• WPF - they haven't done any improvement to WPF for ages (the reason I moved to UWP, after fighting it for so long, is that I've hit WPF's performance bottlenecks and there was nothing more I could do - and trust me, I've tried everything)

[pag3]

@Aminator - Thank for your excellent post and for all the work that went into figuring out and documenting this solution for the community. You’re correct: it’s possible to build UWP apps using .NET 5 already today, as you’ve shown, with some gotchas and limitations as you also wrote. In addition to the way you show, there are other approaches that can work, eg. starting with the packaged desktop app templates we’ve been shipping with the WinUI 3 previews and modifying them to have the apps execute/run as UWP apps instead of desktop apps.

We’d like to figure out the right path to enable this end-to-end, including not just the core platform and runtime working but also the tooling, project templates, deployment, store, etc. We’d like to support this in a way that’s forward-looking, durable, and makes it reasonably easy for developers to build apps with the benefits of UWP and the benefits of the latest .NET.

In terms of being more open on the approach and roadmap here, we’ll aim to post a discussion topic in the next few weeks to share some thinking and collect the community’s feedback. We’re also open to working to understand ways to better support the community in the short term – given the interest in the solution you posted – while also designing and developing a longer-term solution.

I'll be on WinUI Community Call tomorrow (http://aka.ms/winuicall) to answer questions about this as well.

[lukemcdo]

Can you post back some of the Q&A here? I can't realistically make community calls.

[robloo]

Here are my questions related to this discussion: Just focused in a different way but nothing really new. I was going to create another issue but then found this one.

1. .NET Native : .NET Native was put on maintenance some time ago. There are many development issues surrounding this tech and various gotchas in production apps. It's quite painful to discover code that works fine on a dev computer in debug mode crashes on release after going through the .NET Native toolchain. This whole experience needs to be more like Xamarin.iOS. I thought after the full AOT compiler changes made for WebAssembly we would be hearing a story around the future of .NET Native. My expectation was it would be going away in favor of a different compiler altogether -- one shared with Xamarin.iOS and ASP.NET client-side Blazor (webassembly). Microsoft said as much various places a year or so ago but has been silent since.

2. UWP is stuck on version 7.x of C#. C# 9.0 is coming out soon and we need to start adopting a lot of the new features to keep code bases synced. When is UWP getting C# 8/9 support?

3. When is UWP going to run on top of .NET 5/6? (both 1 and 2 relate to this).

[robloo]

@Felix-Dev I agree with your analysis.

What I am seeing here is this: No team at MS wants to be responsible for UWP on .NET 5:

The .NET team -> Absolute silence in both Preview blog posts and on their repo
The WinUI team -> Project Reunion might be used here to bring .NET 5 support to UWP
The Project Reunion team -> Ask the .NET team.

Is the state of the UWP really so pitiful internally at MS that more than a year after the intial introduction of .NET 5 the UWP developer community has zero clue at all how and when support for .NET 5 will arrive? Are we UWP developers that unimportant to MS that seemingly no one wants to step up, lead that project and have a respectful and constructive interaction with the community?

There is a more optimistic interpretation -- athough unlikely I'll admit -- that the future of UWP relates to future versions of Windows such as 10X. If that's true, they may not be able to share what's coming quite yet. So instead of nothing, there is something, it's just confidential. I still see UWP apps are required for XBox, Hololens, et al. and Win32 isn't going to work there.

Unless the rumors about Windows 10X switching over to a web-first approach are true. Then all bets are off and I need to be switching to ASP.NET/React Native yesterday.

[maxkatz6]

@robloo

1. There is some new information about AOT in dotnet from MS. Check Investigating LLVM as a general backend for x86, x64 and arm64 code generation dotnet/corert#8230 and https://github.com/dotnet/runtimelab/tree/NativeAOT . But it seems to be in .Net 6 or even 7.

2. You can use most of features from C# 8 and 9. But part of them will have limitation (when target UWP, you can't see nullability attributes in BCL) and another part could require adding some hack (like you need to add your own Range/Index/IAsyncEnumerable classes to make them works with new syntax). As far I know, only default interface methods are not supported at all. But I totally agree with you, it should works out of box without issues above.

3. I would like to know it also. On latest WinUI youtube stream they said, "even thought developers can already use .Net 5 with UWP (referencing solution from @Aminator ), it will take more time to make everything more transparent for developer". As I understand, not earlier than .Net 6 (as well as DotNet AOT).

[Sergio0694]

Yeah what @maxkatz6 said is correct, you can basically use all the C# 8 features that are syntactic sugar.
The only things you can't use are really just default interface methods and indices/ranges.

@robloo You just need to add:

<LangVersion>8.0</LangVersion>

To your .csproj file and you'll be good to go! 👍

Also yeah, the project-wide nullable setting won't work, and the BCL won't be annotated. That said, you can still add #nullable enable at the start of each file, and then use nullable reference types, the compiler will work you correctly when needed.

Regarding IAsyncEnumerable, for that you just need to reference the Microsoft.Bcl.AsyncInterfaces package.

[robloo]

@maxkatz6 Thanks for the linked issues and your comments. I did not know about the CoreRT issue and am glad to see this discussion documented some place.

@Sergio0694 Thanks for your comments as well:

You can use most of features from C# 8 and 9. But part of them will have limitation (when target UWP, you can't see nullability attributes in BCL) and another part could require adding some hack (like you need to add your own Range/Index/IAsyncEnumerable classes to make them works with new syntax). As far I know, only default interface methods are not supported at all. But I totally agree with you, it should works out of box without issues above.

Yeah what @maxkatz6 said is correct, you can basically use all the C# 8 features that are syntactic sugar.
The only things you can't use are really just default interface methods and indices/ranges.

Do you both honestly think this is safe with .NET Native? I know there are work-arounds like you stated. I have always avoided them for fear of running across a feature that isn't implemented like I think it is which causes issues in production. I think there are a lot more areas affected than you imply. If there weren't Microsoft would have officially enabled C# 8 support a while ago. Also note that the main feature in C# 8 in my book is nullable reference types. This seems all too dangerous in production code without official support.

[charlesroddie]

@brabebhin WinUI doesn't support AOT compilation which is important for performance (especially startup) and code security.

[Pinox]

@brabebhin If WinUI supported AOT, then this tread would not exist. That is the problem, MS failed to provide an alternative and reliable upgrade path.

MS should show much more support to someone like Andrey Kurdyumov @kant2002
https://codevision.medium.com/

If there is one guy that can make it work it's Andrey.

[brabebhin]

Net native used by UWP is buggy and often results in failed builds when adding new stuff, or unexpected runtime behavior, and it is more trouble than it's worth. The reality is the vast majority of developers did not want to waste their time with it. This is not something people want to invest in. I myself found several bugs with it.

AOT compilation is surely something that's needed and I am sure it will come in a form that is actually usable.

[pfresnay]

@brabebhin I agree that netnative is buggy ans WinUI is future, but it does not provide all current UWP XAML stack (we are currently using InkCanvas, Map, MediaPlayerElement) so we simply can not migrate to WinUI3 right now, and Microsoft WinUI3 roadmap does not suggest any date for these features (not before 2022, maybe later or never ?). So we must wait and continue using old C#, old .NET, and old third party libraries... very frustrating! I
hope WinUI team will consider fully replace UWP XAML stack more quickly so we can move out of UWP!
A good news: Webview2 team change its plan ans is currently working on a UWP implementation that will be available soon.

[kant2002]

@Pinox thanks for kind words. I think I receive a lot of support in form of reviewing my PR and helping me dive into CoreCLR/NativeAOT codebase. You overestimate my involvement, since most of my work is just testing and writing articles which show what is currently working, and occasionally fix bugs. Trust me, I'm not most efficient contributor to NativeAOT.

I would like to as @brabebhin or any WinUI developer how can I build and run WinUI application only via console, that tremendously help with WinUI + NativeAOT support. I can be reached over email, or finding me in C# discord (low-level channel).

Also maybe that issue can be forgotten for good, for every reader of it.

[brabebhin]

For mediaplayerelement I have created almost everything custom, the only missing part is fullscreen, which can be achieved with borderless window and a display request.

[pubtom]

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

[jfranki]

@pubtom I've been following all the news, interviews, discussions etc. on the topic and for me at least UWP as we know it is a dead end. We have invested in it and we are not happy about it either, but we are hopeful that WindowsAppSdk will have feature parity in the near future and the migration could be a lot worse.
My advice would be not to wait for .NET 6> (forget .NET 5) support for it because it has a very very VERY low probability of happening.

[JaiganeshKumaran]

Even WPF and WinForms, which are much older than UWP, get .NET 6 but UWP doesn't. This isn't fair.

[riverar]

@JaiganeshKumaran Life isn't fair. Move on.

[robloo]

@JaiganeshKumaran Life isn't fair. Move on.

Certainly true. Kind of insensitive though to put it mildly. Basically saying stop your childish wining.

Microsoft's long history of dropping support for what they once pushed onto developers as the future and reinventing things every few years when management changes is hard to stomach though. Poor management direction is a key takeaway here.

Microsoft is actively working against devs in this case and worse, working against the very devs that trusted Microsofts UWP promise that it was the future. These devs are the early adopters. Not a good way to run a company.

The UWP community is small enough this doesn't matter though and in another 1-2 years once missing features are added to WinAppSDK and we have NativeAOT the migration will be possible. My company isn't waiting for that though. Find another UI framework, cross-platform ones exist that don't have Microsoft's terrible management track record.

[pubtom]

@JaiganeshKumaran Life isn't fair. Move on.

It is incredibly how Microsoft nowadays treat developers. Like this statement. ahhh...
If Microsoft continue this kind of style than I think Windows will be 1% market share in the future because everybody "Move on" to something else.

[jtorjo]

Microsoft's long history of dropping support for what they once pushed onto developers as the future and reinventing things every few years when management changes is hard to stomach though. Poor management direction is a key takeaway here.

The Microsoft's management can be summed up by "Indecision is the key to flexibility".

I wish I could laugh at this, but the opposite is true. There's just so many things that are wrong here, that, to quote myself, I could write a book.

I used to more than love Windows programming -- back when I was working on WinForms/WPF projects. Everything was just working. Now, there are countless bugs because of the great "Windows RetardedTechnology", and I already know they will pretty much never be fixed. Just imagine how bad things are (under the hood) if it's taking so much to port things back to win32. No clear roadmaps, everything just in mid air.

You just can't rely on anything, at this point, no matter what you use, WinUI3, UWP, WPF, at some point you'll hit road blocks -- which can set you back for months.

To say the current state of affairs is sad is an understatement.

[HppZ]

@jtorjo Now, there are countless bugs.

TRUE.

[wherewhere]

Has any interesting to find a way to write UWP on .NET6 normally? I found that using Windows App SDK can debug and package a UWP. But I still have no idea to use XAML with Windows.UI.XAML or WAS.
This is my repository:
https://github.com/wherewhere/CoreAppUWP

[pfresnay]

UWP with recent .NET6/7 would be great! WinUI3 isn't on-par with legacy UWP+WinUI2 stack.

[wherewhere]

But dotnet6 don't have .net native. It will be slower than normal UWP.
(By the way, dotnet 6 on UWP support Hololens. So I think it's the only way to bring new dotnet to non-desktop platforms.

[brabebhin]

Actually the performance part really depends on what you are doing.
Some UWP apis are so slow that when they are replaced with their .net equivalents, the applications become several times faster and negate any impact the lack of net native had on performance.

[driver1998]

UWP with .NET 7 and Windows.UI.Xaml is possible with hacks: https://github.com/driver1998/NetCoreApp.

WinUI 3 on UWP is blocked these days, trying to call Microsoft.UI.Xaml.FrameworkView.Initialize in UWP will trigger an exception, even in 1.4 experimental.

Interestingly, there is CoreWindowSiteBridge and friends in Microsoft.UI.Xaml.Content on experimental channel, and Microsoft.UI.Composition APIs do work in UWP. Just no way to initialize WinUI 3 XAML right now.

[driver1998]

A hack to allow WinUI 3 work again on UWP, tested on WASDK 1.4.2: https://github.com/driver1998/HookCoreAppWinUI.

[wherewhere]

https://github.com/wherewhere/CoreAppUWP

[LancerComet]

Without support for .NET Native it's impossible to publish the application to the Microsoft Store. If a program doesn't need to be published to the Microsoft Store, honestly whether to use UWP or not doesn't really matter.

[driver1998]

If a program doesn't need to be published to the Microsoft Store, honestly whether to use UWP or not doesn't really matter.

It does matter on non-desktop platforms, at least UWP with .NET 8 and Windows.UI.Xaml runs on IoT Core (you'll need the somewhat niche ARM64 IoT Core though), and some other people are exploring Xbox Dev Mode.

Also NativeAOT works just fine on UWP, with that Microsoft Store won't detect it as a .NET app. But currently CoreCLR won't pass WACK dotnet/runtime#96510.

[LancerComet]

If a program doesn't need to be published to the Microsoft Store, honestly whether to use UWP or not doesn't really matter.

It does matter on non-desktop platforms, at least UWP with .NET 8 and Windows.UI.Xaml runs on IoT Core (you'll need the somewhat niche ARM64 IoT Core though), and some other people are exploring Xbox Dev Mode.

Also NativeAOT works just fine on UWP, with that Microsoft Store won't detect it as a .NET app. But currently CoreCLR won't pass WACK dotnet/runtime#96510.

IMO this is a scenario where users need to manually sideload an UWP package, which is difficult to ask users to do. And when enabling DevMode on Xbox to sideload UWPs the user's Xbox no longer functions as a normal Xbox, and it also requires a developer account of Microsoft Partner Center. I just think forcibly fitting .NET into the existing UWP doesn't make much sense, as it can't be published as a normal app to the Microsoft Store. For developers who simply want to develop and distribute software normally, currently the only viable solution is to use the traditional UWP approach. I hope Microsoft can provide a successor plan for UWP, rather than requiring developers to use some kind of magical workaround to implement new solutions.

BTW thank you for posting the issue, is the community currently practicing the use of NativeAOT on UWP?

[dgellow]

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.

🎉