Aminator commented 4 years ago

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

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

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

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

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

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

driver1998 commented 4 years ago

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

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

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

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

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

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

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

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

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

olugt commented 4 years ago

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

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

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

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

robloo commented 3 years ago

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.

.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.
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?
When is UWP going to run on top of .NET 5/6? (both 1 and 2 relate to this).

robloo commented 3 years ago

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

@robloo

There is some new information about AOT in dotnet from MS. Check https://github.com/dotnet/corert/issues/8230 and https://github.com/dotnet/runtimelab/tree/NativeAOT . But it seems to be in .Net 6 or even 7.
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.
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 commented 3 years ago

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

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

maxkatz6 commented 3 years ago

@robloo I had some weird but rare exceptions with IAsyncEnumerable in Release with .Net Native, not stable enough yeah. But another features from C# 8 works well for me. For instance, pattern matching (new switch) and ranges (with https://github.com/bgrainger/IndexRange). Nullable in UWP is dangerous with only one reason - whole BCL and WinRT will not be covered with it, so compiler couldn't warn you about unsafe null.

By the way, it's a great question, will WinRT/WinUI ever be covered with nullable attributes? Does C++WinRT support anything like that?

robloo commented 3 years ago

Nullable in UWP is dangerous with only one reason - whole BCL and WinRT will not be covered with it, so compiler couldn't warn you about unsafe null.

Yes, I'm more concerned about my backend code. I'm aware of these other limitations. Anyway, I don't want to stray too far off topic.

By the way, it's a great question, will WinRT/WinUI ever be covered with nullable attributes? Does C++WinRT support anything like that?

That's a huge change in multiple areas. My guess: No. WinRT changes are few and far between but it could be possible in C#/WinRT I would guess. C++ doesn't -- and can't I would say -- have anything like this. It's a C# language feature only possible in managed code.

DjArt commented 3 years ago

That's a huge change in multiple areas. My guess: No. WinRT changes are few and far between but it could be possible in C#/WinRT I would guess. C++ doesn't -- and can't I would say -- have anything like this. It's a C# language feature only possible in managed code.

«Nullable reference» - it's just attribute, langs that's doesn't support that will just ignore it, so it can be easily done.

Felix-Dev commented 3 years ago

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.

@pag3 You wrote this more than two months ago, do you have an update for us? Can we still expect further progress on .NET 5 for UWP being made public this year?

huoyaoyuan commented 3 years ago

Can we still expect further progress on .NET 5 for UWP being made public this year?

@Felix-Dev As latest WinUI roadmap says, WinUI with .NET 5 for UWP will come at post-3.0. But classic UWP xaml and non-ui components might work before that.

pfresnay commented 3 years ago

Can we still expect further progress on .NET 5 for UWP being made public this year?

@Felix-Dev As latest WinUI roadmap says, WinUI with .NET 5 for UWP will come at post-3.0. But classic UWP xaml and non-ui components might work before that.

Does it meen that Webview2 will be available to WPF & WinForms in a few weeks but not UWP until 1 year ? It's going to be critical when Win10 20H2 will be deployed and legacy Edge will be replaced: no more web developer will care about EdgeHTML support...

robloo commented 3 years ago

My impression: UWP was dropped (extremely low adoption by both devs and consumers) and put on maintenance mode. It will only exist as WinUI on top of WinRT going forward with project reunion integrating the WinRT api's and application model I would think. Packaging should come along too. Since UWP is dead in one sense -- but its pieces will live on -- it seems the team behind its development was effectively disbanded and there is no one left to make these updates integrating what are now separate pieces. My guess is we are all SOL until .net 6 time-frame at the earliest.

WinUI 3 will include Webview2 and support UWP when it launches though. This means that use case should happen faster whenever WinUI 3 is completed next year.

DjArt commented 3 years ago

legacy Edge

This component will not disappear anywhere. After all, it will be necessary to support applications already using it.

jtorjo commented 3 years ago

My impression: UWP was dropped (extremely low adoption by both devs and consumers) and put on maintenance mode.

I really hope this is the case, with a caveat - as long as win2d will work on Desktop apps.

sukesh-ak commented 3 years ago

Updated roadmap here. https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

pfresnay commented 3 years ago

I opened a new issue to ask details for .NET 5 UWP meaning

3328 https://github.com/microsoft/microsoft-ui-xaml/issues/3328

sukesh-ak commented 3 years ago

I opened a new issue to ask details for .NET 5 UWP meaning

3328

It's all confusing terminology and projects.

I will wait to hear official explanation but I believe UWP app means something which works on all forms of Windows OS (desktop, Xbox,IOT etc)

Right now looks like only .NET 5 "Desktop" app using WINUI3 is supported. This is my understanding.

Felix-Dev commented 3 years ago

Bringing to the attention of @pag3 (who should probably be aware of this already): The bottleneck for all things UWP + .NET 5 (.NET Standard 2.1) considered (like EF Core 5.0 support) seems to be put firmly into Project Reunion's basket by other teams at Microsoft:

We're holding off on UWP work while we see where things evolve with Project Reunion. In general the experience with EF Core and UWP is not very good. We hope that in the future we'll be able to create and document a great experience as the U.I. platform evolves.

(Statement of the EF team made here.)

It would be great if we, the UWP community, would get the feeling that this work is a top priority for the responsible teams at Microsoft. Unfortunately, it doesn't feel like that at all. MS's silence on this matter is deafening. We are getting way more replies of the nature "not my problem" than any actual outlook.

Perhaps we really will get a new UWP roadmap for .NET 5 in the next 1-2 weeks (it has been around 10 weeks now since your initial reply in this thread). But the way the communication from MS's side with the community is on going, I'm afraid we could also sit here 6 months from now and still be none the wiser.

@pag3 I know it is unfair to unload all the frustrations onto you, but then again, there is hardly anyone at MS who apparently wants to feel responsible for UWP support for .NET 5 (see the quoted reply of the EF team above, for example). Other MS employees, like @richlander who apparently worked on that story at least in the past have also been very shy on a public updates for months now. So you kinda jumped into a pool full of hungry sharks when you wrote your initial reply 😁

Edit: Yes, we got an updated WinUI 3 roadmap at Ignite which states that .NET 5 support for UWP will come past WinUI 3.0. But that's not really telling us much at all. When will it actually come then? "Post WinUI 3.0" could still means years off from now. How will the support look like? Questions like these are left entirely unanswered by that roadmap update.

brabebhin commented 3 years ago

The way i see it, pure "UWP" applications, let's call them sandboxed, are not really on the radar anymore. And they don't make sense, ever since windows phone was killed, they killed UWP app model.

With project reunion and winUI, they seem to push for "desktop" apps which will have access to all the WinRT apis that are NOT UI related. This will completely make sandboxed model obsolete. The privacy aspect will be fixed in other ways, windows 10 already has ways of limiting desktop apps access to resources without a sandbox.

ptorr-msft commented 3 years ago

The way i see it, pure "UWP" applications, let's call them sandboxed, are not really on the radar anymore. And they don't make sense, ever since windows phone was killed, they killed UWP app model.

Just want to point out that "sandboxed apps" ("UWPs") are definitely still on the radar for Windows Desktop (and other Windows devices like HoloLens etc.). Reunion is about taking the best of UWP and Win32 and letting developers choose the features they want. It will take longer than most people would like (including us!) but that is the direction we are moving in.

If you want the security and privacy protections of the AppContainer sandbox, you should be free to use it. But if you don't want those protections, you should be free to not use it, too. Some of the most painful limitations with the sandbox (like #8, accessing files outside your container) are covered by Reunion Issues; if you have others, please add them :).

jtorjo commented 3 years ago

Just want to point out that "sandboxed apps" ("UWPs") are definitely still on the radar for Windows Desktop (and other Windows devices like HoloLens etc.). Reunion is about taking the best of UWP and Win32 and letting developers choose the features they want. It will take longer than most people would like (including us!) but that is the direction we are moving in.

@ptorr-msft Please let me start off with the following: you've been nothing but helpful, so I have the utmost respect for you.

I will add a bit more flame to the fire - while I truly love UWP (even though it's taken me a lot of time to get there ;)), I definitely think that MS giving developers a choice between sandboxed and non-sandboxed is the way to go.

And while sandboxed is a nice idea, and I've really done my best to adhere to all the possible guidelines out there, I don't think UWP (to read: sandbox) has a future. And it's not because of the sandbox itself, it's because of the many limitations, and to me (and a lot of others, I may say), is simply because most MS developers dread working on WinRT issues. I've added some WinRT issues since 1 year ago, none is fixed and I doubt any will be.

Let me give you a few examples:

Access violations in corelib.dll -- these give me the creeps. I've had a few myself, and once something like this happens, there's nothing my app can do. As far as I can understand, in order for MS to be able to do something, a full crash dump is needed. I've provided this when I could (when I can figure out to constantly reproduce it), but most of the time, it's random.

If I can repro constantly, I usually can figure out a workaround, so I'm good. The problem is when it happens on the customer's computer -- in my case, I only had a few report it, and they don't want to take the time to get a proper core dump. I have no idea how many have actually encountered this, because pretty much no one will bother to let me know -- they'll just stop using my app, give me a 1-star rating and be done with it.

The async exceptions/stack tract -- when an exception happens in an awaited task, it will be caught in the awating thread, with the original stack trace lost. So I'm completely in the dark.
Compilation times, and the like. We've been promised improvements for a loooong time, but nothing happens. My app now compiles in roughly 3 minutes, and I've jumped through a LOT of hoops to improve on that. Like, create lots of small test solutions for certain parts of code (it's taken me quite a lot of time to make that happen). You would think -- going from one solution to another and compiling (it's simply a different set of projects to compile) would work -- this is hardly the case. I've had some compile errors I could write a book about. Imagine this -- most errors would go away after doing a "clean" (not the "Clean from VS, but "Clean" -- as in removing the "bin" directory), but some will go away only after doing a Clean and rebooting. This is beyond unacceptable in 2020.
Bonus: I've had one issue that made me laugh in tears -- it was a stack overflow exception masquerading as an an access violation (meaning: I actually got the Access violation exception, which basically didn't allow me to even put breakpoints. Nothing worked -- the app would crash during startup, and no matter where I would place breakpoints, it wouldn't work). Basically 2 functions calling each other on a timer that called an async function (I couldn't repro on a simple crafted example, I tried). I realized what the issue was by simply slowly going back one checkin at a time, figuring out what I've changed, and all that. This should simply not be an issue -- I'm sure had it been a desktop app, it would not have happened.

I have plenty more issues, but the above are the most important. My point is this -- even though I pretty much hate WinRT, I would certainly live with it, if it was actually "predictable" -- when an error happens, just get a decent stack trace, and be somewhat able to reproduce, be able to understand what happened. This is rarely the case.

And to add more flame -- in Desktop apps, you could use .pdb files to understand the exact line from a stack trace (when an exception happened). This doesn't work on UWP / release mode. So, even on a 10-15 line function, when I get a null exception or argument exception -- I am scratching my head as to what could have caused it.

I would really love to hear from more UWP developers, as to what they think. My opinion is beyond bleak. All I'm doing is write code and pray it won't go bonkers, until win2d is fully ported to Desktop (this is the only reason I switched to UWP - for win2d).

rgwood commented 3 years ago

@jtorjo Not to dismiss your issues, but I think a number of them are more to do with the .NET Native compiler than the AppContainer sandbox.

As a UWP developer I am generally happy with the sandbox, and I am extremely unhappy with the .NET Native compiler. YMMV, of course.

jtorjo commented 3 years ago

@rgwood I wish that was true. I don't use .NET Native compiler at all. It used to crash on me a lot of times, because of the fact that I use naudio and log4net. So basically I turned it off pretty much one year ago.

Every now and then I do an experiment -- which always fails (try to compile on .net native). 2.6.9 clearly has failed from the get go. So does 2.6.10 -- I often laughed at just "how much" was achieved from 2.6.9 to 2.6.10 (please look at the release notes, have a glass of wine, and then a few laughs -- good times).

Sergio0694 commented 3 years ago

@jtorjo can you clarify what you mean with "you disabled the .NET Native compiler"? Even if you don't use that locally, if you upload a UWP app to the Store, the Store will always compile it with .NET Native remotely - users can just never install UWP apps not using the .NET Native compiler, that's simply not supported at all as far as I know.

I mean, I never use the .NET Native compiler locally either as it takes too long to build, and because you don't need that to create Store packages anyway (even if you use .NET Native, that build is only used for the local certification tool, but the actual package you upload to the Store only contains IL code, not the native binaries), but the Store will still use that remotely. Maybe there's some confusion here? 🤔

Also, regarding this:

And to add more flame -- in Desktop apps, you could use .pdb files to understand the exact line from a stack trace (when an exception happened). This doesn't work on UWP / release mode. So, even on a 10-15 line function, when I get a null exception or argument exception -- I am scratching my head as to what could have caused it.

That's not actually true though. Eg. if you use AppCenter for the crash reports, it will automatically pull the .pdb files from the Store and will display accurate stack traces with symbols, and will often times even be able to indicate the exact line of code that triggered the crash, and it will also be able to annotate async stack traces more often than not:

(Note: what I said applies to fully UWP apps in C#/XAML)

lukemcdo commented 3 years ago

It’s still technically possible to upload an NGEN app (last-gen 8.1 tech) AFAIK? That would qualify.

77376 commented 3 years ago

@jtorjo

definitely think that MS giving developers a choice between sandboxed and non-sandboxed is the way to go. And while sandboxed is a nice idea, and I've really done my best to adhere to all the possible guidelines out there, I don't think UWP (to read: sandbox) has a future. And it's not because of the sandbox itself, it's because of the many limitations, and to me (and a lot of others, I may say), is simply because most MS developers dread working on WinRT issues. I've added some WinRT issues since 1 year ago, none is fixed and I doubt any will be.

Let me give you a few examples:

1. Access violations in corelib.dll -- these give me the creeps. I've had a few myself, and once something like this happens, there's nothing my app can do. As far as I can understand, in order for MS to be able to do something, a full crash dump is needed. I've provided this when I could (when I can figure out to constantly reproduce it), but most of the time, it's random.

2. The async exceptions/stack tract -- when an exception happens in an awaited task, it will be caught in the awating thread, with the original stack trace lost. So I'm completely in the dark.

And to add more flame -- in Desktop apps, you could use .pdb files to understand the exact line from a stack trace (when an exception happened). This doesn't work on UWP / release mode. So, even on a 10-15 line function, when I get a null exception or argument exception -- I am scratching my head as to what could have caused it.

I would really love to hear from more UWP developers, as to what they think. My opinion is beyond bleak. All I'm doing is write code and pray it won't go bonkers,.

A Full Crash Dump and Decent Stack Trace have been two most wanted capabilities for sandboxed apps since the beginnings. you know what, MS doesn't give a damn about sandboxed app devs.

until win2d is fully ported to Desktop (this is the only reason I switched to UWP - for win2d)

this is why, when win32+winUI happens(which is project reunions main priority), "sandboxed app model+ their too much limited capabilities" will no longer make any sense. eventually sandboxed app model/UWP dies.

77376 commented 3 years ago

@ptorr-msft

Just want to point out that "sandboxed apps" ("UWPs") are definitely still on the radar for Windows Desktop (and other Windows devices like HoloLens etc.). Some of the most painful limitations with the sandbox (like #8, accessing files outside your container) are covered by Reunion Issues; if you have others, please add them :).

way too much restrictions are the most painful. anything that tries to modify the system should be restricted from sandbox/pure UWP apps, but other than all that, developers should be given freedom to produce something useful beyond "some data fetching from the internet and displaying" clients.

jtorjo commented 3 years ago

@Sergio0694

About me disabling the .net native compiler -- the reason I did it is because it crashes at compile time. It's got something to do with the fact that I use naudio and log4net. This was never fixed, so I never turned it back on.

Even if you don't use that locally, if you upload a UWP app to the Store, the Store will always compile it with .NET Native remotely - users can just never install UWP apps not using the .NET Native compiler, that's simply not supported at all as far as I know.

Of course, if you use the Store, then you're in deep doodoo. But you CAN publish an app outside the store - it's far from trivial, mind you, but it's doable. My app has been published outside the store from the get go (close to 1 year now).

That's not actually true though. Eg. if you use AppCenter for the crash reports, it will automatically pull the .pdb files from the Store and will display accurate stack traces with symbols, and will often times even be able to indicate the exact line of code that triggered the crash, and it will also be able to annotate async stack traces more often than not

I do use AppCenter -- I see the stack trace, but on async code I never get the whole stack. And I NEVER EVER get the line that caused the crash. Trust me, I've analyzed stack traces from AppCenter for over 6 months now.

brabebhin commented 3 years ago

Just want to point out that "sandboxed apps" ("UWPs") are definitely still on the radar for Windows Desktop (and other Windows devices like HoloLens etc.). Reunion is about taking the best of UWP and Win32 and letting developers choose the features they want. It will take longer than most people would like (including us!) but that is the direction we are moving in.

If you want the security and privacy protections of the AppContainer sandbox, you should be free to use it. But if you don't want those protections, you should be free to not use it, too. Some of the most painful limitations with the sandbox (like #8, accessing files outside your container) are covered by Reunion Issues; if you have others, please add them :).

File access issues described in #8 are just a small drop in a very, very big ocean. Basically, almost every subsystem of windows has similar problems.

Take for example networking:

Why can't applications work properly with .net API such as HttpListener on port 80? Why can't applications somehow register themselves as services in SSDP? Many modern networking frameworks, such as RabbitMQ, SignalR server, do not work on UWP.

To achieve a simple advertisement with SSDP for a HTTP server, we need to jump through hooks with custom ports, adding all sorts of manual setups for the users, or relay on one of the more "modern" and "exotic" technologies such as bluetooth LE aderts, instead of using something that's truly universal.

Bugs that have been reported, such as the inability to use MediaPlaybackList with IBasicVideoEffect (due to MediaPlaybackItems getting randomly skipped) are never fixed

The worst part is that the UWP app model makes you dependent on winRT to get things done. If you are missing/limited on a feature, well then though luck. At least with a fully featured .net API you could implement your own.

And last but not least, why all the async methods? Why not provide both async and sync methods? async does not make you inherently fast, quite the opposite.

I can understand what you are saying, that Microsoft wants to continue to support the sandbox model, but frankly, their own actions point to something else.

jtorjo commented 3 years ago

That's not actually true though. Eg. if you use AppCenter for the crash reports, it will automatically pull the .pdb files from the Store and will display accurate stack traces with symbols, and will often times even be able to indicate the exact line of code that triggered the crash, and it will also be able to annotate async stack traces more often than not:

@Sergio0694 @ptorr-msft

Just to give you a glimpse on the stuff I need to deal with on a daily basis, trying to maintain my sanity:

This happens on roughly 1 out of 25 machines. There's SIMPLY NO WAY TO REPRODUCE. What am I supposed to do, as a developer?

77376 commented 3 years ago

@mcosmin222 @jtorjo

It all started the day when microsoft's Kevin Gello announced XAML Islands in 2017 and after 3 years we all know what it has become ~ the ProjectReunion....

in App Development Community Standup: Project Reunion Update held in july in youtube , Kevin Gallo mentions they're working on method of reusing AppModel sandboxing mechanism to also sandbox unmodeled win32 apps @31:57

so, do you think UWP will have any single worth when unmodeled win32 apps could be fit in the sandbox within it's superior functionalities set compared to toyish UWP ? Smell something?

77376 commented 3 years ago

so, do you think UWP will have any single worth when unmodeled win32 apps could be fit in the sandbox within it's superior functionalities set compared to toyish UWP ? Smell something?

according to MS's own current actions,

apparently the future becomes win32+.NET "X"+winUI wrapped in the sandbox mechanism Kevin Gallo was referring there. and this win32 sandboxed apps maybe(/should) able to run on all windows based platforms once it's done.

now every action of MS regarding UWP makes sense, now I can see why MS never went all in UWP. If wrong, I would like to get this corrected someday. 🙂

microsoft / WindowsAppSDK