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: .NET 5 UWP apps are already possible, so when will official support arrive? #105

Closed
Aminator opened this issue Jul 10, 2020 · 224 comments
Assignees
Labels
area-DeveloperTools Issues related to authoring (source and IDL), debugging, HotReload, LiveVisualTree, VS integration area-UWP Support for UWP apps

Comments

@Aminator
Copy link

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
Copy link

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
Copy link
Author

@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
Copy link

Pinox commented Jul 10, 2020

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
Copy link

Felix-Dev commented Jul 10, 2020

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

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

@LeftTwixWand
Copy link
Member

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

@driver1998
Copy link

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
Copy link

olugt commented Jul 10, 2020

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
Copy link

@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
Copy link

Pinox commented Jul 10, 2020

@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
Copy link
Contributor

@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
Copy link

stevenbrix commented Jul 10, 2020

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
Copy link

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
Copy link

pjmlp commented Jul 10, 2020

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
Copy link

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

@olugt
Copy link

olugt commented Jul 10, 2020

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
Copy link

jtorjo commented Jul 14, 2020

@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
Copy link

pag3 commented Jul 15, 2020

@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
Copy link

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

@robloo
Copy link

robloo commented Jul 22, 2020

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
Copy link

robloo commented Jul 23, 2020

@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
Copy link

maxkatz6 commented Jul 23, 2020

@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
Copy link

Sergio0694 commented Jul 23, 2020

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
Copy link

robloo commented Jul 23, 2020

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

@sukesh-ak
Copy link

Looks like .NET 6 timeline (end of 2021) for new apps there are 2 options (in 2021 apps are usually expected to be cross-platform)

  • .NET 6 - MAUI
  • Blazor Desktop

This is what I am looking at for my requirements.
Will discard my work-in-progress on UWP but need to wait a bit for 3rd party controls I need.

The Universal in UWP is not exciting anymore.

@ghost
Copy link

ghost commented May 14, 2021

without any consumer facing (not enterprise) devices , Devs won't never ever come.
what consumer facing devices does MS have to attract devs to develop apps? desktop ? (its enterprise focused only + for gaming ,not consumer device anymore, consumers are on ios and android) , xbox ? (mostly for gaming) , hololens ? (enterprise again).

so what consumer facing devices windows runs on that have the need for new/modern apps?
none really. no consumer facing devices means no devs means no apps means platform dies.
for regular (non enterprise/gaming) app devs , whole windows ecosystem is dead now.
killing windows phone was killing Windows .

@yoshiask
Copy link

It's been over a year since this issue was opened, and .NET 6 is preparing to enter the release candidate phase. Is there still no update on this? More and more libraries have been dropping .NET Standard support entirely, even when they could be (or have already been) multitargeting .NET5+ and .NET Standard.

@HppZ
Copy link

HppZ commented Aug 23, 2021

No hope.

@riverar
Copy link
Contributor

riverar commented Aug 23, 2021

@yoshiask Microsoft announced in July that they had no plans to support "UWP" + WinUI 3. I think it's clear this is not something anyone is working on and you should consider this issue closed.

@yoshiask
Copy link

There's a lot more to WASDK than WinUI 3. It's all the other stuff that I need.

@JaiganeshKumaran
Copy link
Contributor

There's a lot more to WASDK than WinUI 3. It's all the other stuff that I need.

Even then, you can't really use WindowsAppSDK in a UWP app because it pulls in WinUI 3 automatically which will cause metadata errors if you're using WinUI 2.6 already because of duplicated types.

@riverar
Copy link
Contributor

riverar commented Aug 23, 2021

There's a lot more to WASDK than WinUI 3. It's all the other stuff that I need.

I hear ya. It's not coming. Start migration work to WinUI 3 or another stack.

@brabebhin
Copy link

Net core 6 already suppprts winRT natively, the only reason to ever use UWP was winRT. With that out of the way, there is really no point in supporting several ui platforms, now that winUI is basically providing everything UWP XAML did.

@charlesroddie
Copy link

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

@Pinox
Copy link

Pinox commented Aug 24, 2021

@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
Copy link

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
Copy link

@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
Copy link

@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
Copy link

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
Copy link

pubtom commented Nov 29, 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

@jfranki
Copy link

jfranki commented Nov 29, 2021

@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
Copy link
Contributor

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

@riverar
Copy link
Contributor

riverar commented Nov 29, 2021

@JaiganeshKumaran Life isn't fair. Move on.

@robloo
Copy link

robloo commented Nov 29, 2021

@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
Copy link

pubtom commented Dec 1, 2021

@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
Copy link

jtorjo commented Dec 1, 2021

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
Copy link

HppZ commented Dec 1, 2021

@jtorjo Now, there are countless bugs.

TRUE.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-DeveloperTools Issues related to authoring (source and IDL), debugging, HotReload, LiveVisualTree, VS integration area-UWP Support for UWP apps
Projects
None yet
Development

No branches or pull requests