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

[Aminator]

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

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

How to create a .NET 5 UWP app

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

Project file

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

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

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

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

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

  <!--Any XAML files that have a code-behind file need to be listed here.-->
  <ItemGroup>
    <Page Update="App.xaml">
      <Generator>MSBuild:Compile</Generator>
    </Page>
    <Page Update="MainPage.xaml">
      <Generator>MSBuild:Compile</Generator>
    </Page>
  </ItemGroup>

  <!--This target generates a resource file for your app based on the priconfig.xml file and the files in the output directory.-->
  <Target Name="MakePri" AfterTargets="Build">
    <Exec Command="&quot;$(MSBuildProgramFiles32)\Windows Kits\10\bin\$(TargetPlatformVersion)\x86\MakePri.exe&quot; new /pr $(OutputPath) /cf priconfig.xml /of $(OutputPath)resources.pri /o" />
  </Target>

  <!--The manifest needs to be registered with the OS and after doing this, your app will appear in the app list.-->
  <Target Name="RegisterManifest" AfterTargets="MakePri">
    <Exec Command="PowerShell Add-AppxPackage -Register $(OutputPath)AppxManifest.xml" />
  </Target>

</Project>

Package manifest

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

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

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

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

Resources

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

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

Entry point for WinUI 3

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

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

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

Building and debugging

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

Issues

The biggest issues with this approach are:

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

Conclusions

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

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

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

[Arlodotexe]

Thanks for the information, let me try to summarize what we know.

• UWP apps submitted to the store, as it stands now, must be compiled with .NET Native, so submitting an app made with .NET 5 will simply fail when the Store processes it.
  • There is probably a lot of infrastructure that needs to be updated to replace .NET Native with NativeAOT when the time comes. Since the tech hasn't arrived, it's doubtful that work has started.
  • It's also possible that compiling the .NET 5 assemblies to native code, and building a "standalone" app with no dependencies on the shared framework could pass WACK tests in the store, but nobody has tested it yet.
• Visual Studio has no tooling to create a UWP app with .NET 5.

I've gathered some more scraps of info on Project Reunion, .NET 5 and UWP from various places, which paints an interesting picture.

Quoting Ryan Demopoulos from here

It could be that there is a period in 2021 where UWP apps continue to use .NET Native, but then there is a great pathway to Reunion that supports .NET 5 (or, maybe .NET 6 by then), and people can just switch to that.

(Meaning, as far as he knows, the tooling required to create AOT-enabled UWP apps might not arrive until either Project Reunion creates a path, or .NET 6 arrives.)

Rich Lander, program manager of the .NET Core team, said this in December 2019:

I'm one of the people working on this. We're still working on our .NET 5 plan, which includes Xamarin and UWP. Our intention is to enable UWP apps to use .NET Core, which will resolve this request. We'll have more to share when we get through our planning process.

In May 2020 during the "Journey to One .NET" build session, at 1:24:37, Scott Hunter said:

A lot of customers, as we ship .NET Core 3 especially, asked us about: "What about UWP? When is UWP coming to .NET Core?" And the answer is, there's no plan to do that, and that's because the Windows team is introducing something called WinUI. And WinUI is the next iteration of UWP. [...] So if you are a UWP developer, I'd say stay where you're at today, and then watch this WinUI project, as a great place to move your UWP apps when it's available and ready.

In May 2020, John Wiswall, Platform Architect at Microsoft said this:

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

Arthur Vickers, manager of EF said this in September 2020:

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.

Maybe I'm missing pieces of the puzzle, but it seems like there is minimal internal communication at Microsoft about how Project Reunion, WinUI 3, and .NET 5 all fit into the picture for UWP, thus certain key teams that would normally make this happen are left "waiting for Reunion", which circles back to what Ryan said in the first quote.

Are we going to be left waiting for Reunion before we get .NET 5? If so, could we get some transparency on what is happening with Reunion regarding this?

[saint4eva]

@Arlodotexe All of them are just beating around the bush - no transparent information. They should come out and tell us what is happening to UWP internally.

[sukesh-ak]

I think it's easier to ask this way.

Is UWP being killed?

OR

Is UWP waiting for .NET 6?

[duckheadsoftware]

I don't think there will be UWP or Win32 apps going forward. I think they will be ".Net 6 WinUI" apps with the option of using components of the (UWP) security boundary. Probably with a push to merge WinRT and .Net to use a single API. Which makes sense to me at least :)

[Arlodotexe]

I think it's easier to ask this way.

Is UWP being killed?

OR

Is UWP waiting for .NET 6?

Can confirm that UWP is not being killed. Instead, it's being "evolved" in a way.

Steven Brix (here) said in August 2020:

I agree that UWP has a bad name, if you type the phrase "UWP is" into a search engine, the first auto-suggestion Bing or Google will give you is "UWP is dead". However, I do think @marb2000 is right that we should continue to use the name, despite the baggage that it carries. With that being said... Today, many aspects of the Desktop projects will be able to use different parts of what we used to define as "UWP":

The UI stack (aka WinUI3) MSIX Packaging MRT Resources Once CoreApplication is lifted, then the only difference between UWP and Desktop will truly be the sandbox model that you choose for your application and which devices you're able to target.

So @duckheadsoftware is pretty close to on the ball. However, that's neither here nor there.

The point of this thread: I would still very much like to use .NET 5 in my UWP applications today, not in a few years when Reunion is done. Is any work planned or being done to make this happen, or what is holding Microsoft back on this?

[jtorjo]

@Arlodotexe All of them are just beating around the bush - no transparent information. They should come out and tell us what is happening to UWP internally.

@saint4eva @Arlodotexe It's something I've said for a loong time - no one at MS wants to work on UWP, because of the huge amount of clusterf*** WinRT/sandbox has always been -- a half baked idea with no clear direction going forward, very likely pushed in all directions by whomever got in charge. It's become so bad, that no one wants to go near it. Just look at UWP compile times, as a simple example -- we've been promised improvements for ages, nothing has happened, and I'm pretty sure nothing will ever happen.

LATER EDIT: when I said "pushed in all directions by whomever got in charge", I'm really talking about clueless MS managers, I'm not talking about programmers. I do know there are a LOT of incredibly good programmers at MS.

[sukesh-ak]

Problem is that Microsoft itself is not clear on the future. If it was the case, this thread would not be here.

I am waiting to decide what my project UX (IOT + AZURE + UX) should be using since I want it to be available through store for ease of updates and should run on all Windows devices.

Then there is MAUI which I don't know how it's going to play out. Because end of the day I need my app to be available on Android and IOS platforms as well.

[Kade-N]

@Arlodotexe All of them are just beating around the bush - no transparent information. They should come out and tell us what is happening to UWP internally.

So I've been following some news about Windows and its future updates, and current leaks and rumours indicate that Microsoft plans for a major Windows version to launch one year from now (Fall 2021), codenamed Sun Valley. The initiative seems to have began early this year. https://www.windowscentral.com/windows-10-sun-valley-ui-october-2021-update

Also of note, Microsoft just killed a React-based Calendar preview app (to replace the current UWP app) that they were planning to launch. Sources who have a good track record of knowing what's going on inside MS have indicated that the reason for this will be clear in 2021 - which coincides with Sun Valley. https://twitter.com/Daniel_Rubino/status/1319333064951070722

Remember, there's new leadership at Windows now [as of this year]. They're going to shift direction/priorities and I'm confident people are going to like what's coming.

Worth noting that many inbox apps in Windows 10 are UWP but have small components built in React. This naturally leads to a lot of inconsistency, which apparently is what Sun Valley is supposed to solve.

Also of note, Windows 10X is apparently releasing next year as well, and is focused on UWPs and PWAs.

So, it sounds like all of this may be related to the lack of transparency here.

Based on all of that, I'm gonna make a few guesses:

• Win32 in its traditional format is effectively a dead end
• WinUI is a major focus
• Windows 10X is driving changes to Windows 10
• Adding on to that, tablet experiences are getting more attention
• Microsoft may be pulling back on its React efforts (MS is/was heavily using React in new apps... but now at least one has been cancelled, and it sounds like it was in reaction to Sun Valley)
• That leaves UWPs and PWAs
• Possibly a reboot of the whole UWP initiative? The tweet I linked is insanely vague, but all signs seem to be pointing that we're getting something new, it uses WinUI, runs natively on both Windows 10 and 10X, major system components are being built with it, and currently, its top secret at MS.

Whether that new thing involves .NET is my biggest question right now, and remains to be seen. If MS plans to make React the focus for the entire Windows shell and apps I'd be very disappointed, but it sounds like this may not be the case. Or maybe, as some people are guessing, it will just be Project Reunion and you can mix and match frameworks with WinUI, and package it for either Win32 or UWP (though I feel like this doesn't exactly fit the goals of Sun Valley or Win10X).

Either way, I feel like we're not going to get a clear answer from MS until next year.

[yoshiask]

@KyleNanakdewa I think you're right about Sun Valley, but if Microsoft is really moving back towards UWP, why not give developers a heads up? Or at the very least, keep UWP tooling and capabilities up-to-date with other MS tech (WPF/WinUI 3 Desktop/WinForms) instead of treating it as a second-class citizen.

[duckheadsoftware]

@yoshiask I'd like to think that project Sun Valley is all about UWP. UWP with WinUI, .Net 6 and brought right up-to-date with all the fixes we've been asking for. This makes sense when we look at Windows10x (UWP is native, x86 in emulation); it's like "let's experiment and get .Net in order first, then continue with the massive revamp of UWP" :)

[sukesh-ak]

Messaging/Communication from Microsoft has been terrible from UI/UX perspective from the time of UWP (Windows Phone) launch days. Will it be 2022 when we hear what future plans are?

Till Microsoft launches something which is also used for all Windows inbox apps (WINUI?), there is no trust to follow the random announcements anymore.

[sukesh-ak]

Certainly it's a preview, and that means I shouldn't expect much, but WinUI 3 preview 2 was disappointing for me.

My biggest need is in the area of XAML designing. I was pretty taken aback by the fact that the XAML designer didn't work at all, and so far I've found no clear information as to when it will.

What happened to Blend? I haven't tried it from long. Does it even work now?

[pjmlp]

@sukesh-ak It does still work, provided you are doing WPF or classical UWP, still no roadmap in sight for Reunion and post UWP world.

[Arlodotexe]

@sukesh-ak @ericleigh007 Could you please open a different issue for this, to keep this one on-topic?

[ericleigh007]

@sukesh-ak @ericleigh007 Could you please open a different issue for this, to keep this one on-topic?

This was in the wrong issue - I had followed a link from #1045 and forgot where I was. Moved. 😎

[olugt]

Good day everyone.

I saw the following:

• Get started with WinUI 3 for UWP apps (https://docs.microsoft.com/en-gb/windows/apps/winui/winui3/get-started-winui3-for-uwp)
• Get started with WinUI 3 for desktop apps (https://docs.microsoft.com/en-gb/windows/apps/winui/winui3/get-started-winui3-for-desktop)
• A GitHub WinUI 3 demo repo by Miguel Ramos (Twitter: https://mobile.twitter.com/marbtweeting) (https://github.com/microsoft/WinUI-3-Demos)
• A quote at an article titled "Windows UI Library (WinUI)"... "This WinUI 3 preview release is intended for early evaluation and to gather feedback from the developer community. It should NOT be used for production apps." (https://docs.microsoft.com/en-gb/windows/apps/winui/)

So, when I asked Miguel Ramos, on Twitter, about the recommended way to create a production-ready WinUI [3?] app with UWP, for example, and using .NET 5 and C# 9, he said...

" Production Ready Today:
UWP XAML + WinUI 2. It uses .NET Native which is .NET Standard 2.0 complaince.

Future: 1) Desktop WinUI 3.0 with .NET 5 - ETA for GA is 2021. 2) UWP WinUI 3.0 with .NET 5. ETA is post WinUI3.0 GA per the current engineering plan. " (https://twitter.com/marbtweeting/status/1328219232711032833?s=20)

So, I hope that answers a lot of questions already.

[olugt]

And as regards Project Reunion (https://github.com/microsoft/ProjectReunion), it has been clarified that it is not an app platform nor other misconceptions, but just a journey with some components already or almost available, e.g. At the following link (https://github.com/microsoft/ProjectReunion/blob/main/docs/README.md), the following components were highlighted:

• WinUI (now almost at full version 3)
• C++/WinRT, Rust/WinRT, and C#/WinRT https://github.com/microsoft/ProjectReunion
• MSIX-Core

And that Project Reunion...

• isn't a new application model
• isn't a new packaging or isolation model
• isn't a new security or privacy model
• isn't a way to run your app in the cloud

[olugt]

And as regards MAUI, it is the next evolution of Xamarin.Forms, according to various sources online.

Also, I do not assume that no one here is aware of my findings. I intended to add the information to the thread, just for clarifications.

[yoshiask]

@olugt Thanks for sharing your findings! I think of us are aware about what Project Reunion is, and that the current production-ready system for UWP is WinUI 2 with .NET Core/Standard. But it's been proven that WinUI 3 with .NET 5 on UWP is entirely possible, albeit difficult to set up with the current tooling. The only thing preventing it from being "production ready" is Microsoft's tooling for such UWP apps. What I want to know is why Microsoft is putting off the tooling for WinUI 3/.NET 5 UWP projects, even though most of the tech is already there.

[marb2000]

@yoshiask Unfortunately, it's not as simple as just tooling. For example, it requires adapting test infrastructure, adding and adjusting unit tests (we have thousands), and integrating into the CI/CD pipelines. We are sure because always happen, that this will have some collateral work in all the layers of WinUI (UI, Input, Composition), maybe even CS/WinRT. It's not a piece of cake; it's pealing the onion work. But we are making progress.

[yoshiask]

@marb2000 Ah, okay, that makes sense. Thank you for actually answering the question! I understand that most of the infrastructure is private, but is there any way that the community can help speed things up a bit?

[marb2000]

@yoshiask Thanks for the offer. It isn't very easy; we need to make it open source first. But for making it open-sourced, we need to decouple from the OS first, which is the first step of some projects of Reunion, like MRT Core (which is currently open sourced) and WinUI 3 (which is working on it). As you see, we are making progress on a lot of things. :)

[sukesh-ak]

OK finally some updates with the latest WINUI 3 Preview 3 announcement.

Check the "WinUI 3.0 Feature Road map" UWP+WINUI+.NET 5 = post WINUI 3 timelines. So my guess is 2022.

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md#winui-30-feature-roadmap

[pjmlp]

Thanks @sukesh-ak

The roadmap is still missing when C++/WinRT will reach feature parity with C++/CX, despite MS forcing us to adopt it.

[robloo]

@marb2000 @ptorr-msft @stevenbrix I think Microsoft can and should adopt a different strategy for the short term. As mentioned before, Microsoft should allow UWP + .net 5 desktop apps to pass store certification. The above work-arounds should be made official and some minor changes to tooling made to support it out of the box.

The store pipeline should be changed so .NET 5 UWP apps are never run through .net natve. C# apps will work on top of the .net CLR calling into WinRT and WinUI APIs which is already possible as mentioned above. As Microsoft dropped mobile support a long time ago I can't think of any significant technical hurdles preventing this. Years ago Microsoft relaxed store restrictions in a similar way to allow in existing desktop apps.

Microsoft must have a solution that isn't 1-2 years away for UWP apps to use current c#/.net/WinUI. I'm much more willing to live without .NET native support in the short term (while the AOT discussion is ongoing for the next few years most likely) than I am willing to stay locked inside no longer updated versions of UWP.

[pjmlp]

I agree with the short term idea, it is getting harder by the day to justify development budgets to keep investing in UWP, specially with the rewrites it requires.

Apparently we should all using React Native now.

[sukesh-ak]

Anyone tried this?

Get started with WinUI 3 for UWP apps

https://docs.microsoft.com/en-us/windows/apps/winui/winui3/get-started-winui3-for-uwp

Does this use .NET 4/Core?

[jamers99]

@sukesh-ak that uses what UWP is currently on, which is a version of .NET Core 2.x.

[sukesh-ak]

@sukesh-ak that uses what UWP is currently on, which is a version of .NET Core 2.x.

Sorry you mean .NET Core 2.x with WinUI 3?

[jamers99]

Yes, although it's not really .NET Core. It's a subset of it and it builds with the .NET Native compiler. Kind of a "UWP .NET Core" is what I've heard it called, although I don't have great sources for this. UWP .NET Core can't reference .NET Core unless that library also targets .NET Standard.

What we want is the UWP app model built on top of .NET 5, just like the WPF app model is on top of .NET 5. That would allow UWP to use .NET 5 libraries and such, further unifying codebases. Everything is just .NET. The only difference between a Class Library, WPF, and UWP project would be the OutputType in the csproj (or something like that 😊).

We dream...

[driver1998]

If you deploy your UWP as Debug, you'll see a thing named .NET CoreUWP, no I don't know what it actually is though.

[sukesh-ak]

If you deploy your UWP as Debug, you'll see a thing named .NET CoreUWP, no I don't know what it actually is though.

I think that's the next version of UWP which will be discontinued to make way for v.next Its been a frustrating experience in the Windows UI/UX apps for such a long time now without a proper direction on the horizon.

There are no simple answers to point to, when the question is What UI/UX platform should I use if I need to build a new product which works on all Windows powered platforms of today and tomorrow (ARM64+10X?) and which can have shared components with Xamarin (MAUI?) of future. Something which will be used to build Microsoft Windows inbox applications (for some assurance).

I want a multi-platform application with code re-use. MAUI doesn't have anything mentioned about UWP other than in the roadmap or initial documentation. All initial samples are for MAUI (Xamarin Forms) and iOS native and Android native.

I don't even know if these discussions are being read by anyone in Microsoft who is responsible to make changes and take decisions to help our life as developers.

[jamers99]

FWIW, .NET 5 UWP support is now on the roadmap, since September. Although it is extremely vague, stating it as a 3.x feature. https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md#winui-30-feature-roadmap

@anawishnoff, some more clarity here would be awesome. Maybe even just a vague date range?

[sukesh-ak]

That green symbol legend says 🟢 - Included, or planned to be included.

So it's already vague and not concrete. Same for inking which is supposed to be one of the operating system input method.

[wjk]

@Aminator Your code no longer works with WinUI 3 Preview 3. The Window type in WinUI 3 is now glued to its desktop app backend, and can no longer be put in a UWP CoreWindow. (Or, more accurately, I cannot put anything into a CoreWindow, since it does not have any public APIs for setting the contents. You used to need to use Window.Current, but that now always returns null.)

[Noemata]

I'd like to see Microsoft answer the following 3 main questions:

(1) Why is the .Net Native compiler being dropped (is it because it's hard)? (2) What will be in place from day 1 for UWP + .Net 5 that will prevent easy decompiling of whatever we publish into the Store? (3) Why does Microsoft never persist with using any of the technologies they thrust on their developer community, the best recent example is what happened with Office Mobile and Skype UWP apps?

I look to Windows system component apps and Microsoft's own product releases to see what Microsoft itself has confidence in within the eco system of tooling they release. WPF apps from Microsoft were/are exceedingly rare, as were/are C# apps. The bulk of their publicly consumable work is traditional C++ Win32 in relative terms. Even some of Microsoft's more interesting UWP efforts were done mostly in C++ (Freshpaint, Office Mobile). Why? I postulate that they too aren't keen on having others reverse engineer their intellectual property. Microsoft clearly lacked confidence in the .Net Native compiler to use it for their own efforts (someone from Microsoft please enumerate the UWP apps that were done in C# that are in the Store today).

The .Net Native compiler held out the promise of leveling the playing field between C++ and C#, especially in terms of perf. When will we actually see something equivalent from AOT?

[sjb-sjb]

@pag3 can you provide a link or give more information on your comment "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."

The approach described by @Aminator is difficult, at least from my point of view, and it would be great to have something a bit more do-able. I need something that can support a UWP-based library and a UWP app that calls it.

For example can I use the WinUI 3 preview templates to create a class library that has all my code in it (including UI) and then call into that from a package/shell that is built using the UWP app template? What if I want to use file pickers, say, can these be in the WinUI class library or do I need an additional class library built with UWP just for that purpose?

[pjmlp]

@Noemata I guess it is the usual WinDev vs DevTools politics that makes us on the outside suffer.

Longhorn, Silverlight, Managed Direct X, XNA, no WinRT bindings for DirectX, and now .NET Native

Meanwhile other platforms are giving higher focus to their managed languages to shine on.

[Noemata]

@pjmlp , sometimes I forget how long the list is. Thanks for the reminder. I'm going to try a different approach until December. It's time I start posting solutions rather than complain about the missteps. 2020 was bad enough, 2021 needs all the help it can get.

[pjmlp]

@Noemata Here is our answer on what will happen in UWP, expect an official answer on Build.

https://blogs.windows.com/windowsdeveloper/2021/01/21/making-win32-apis-more-accessible-to-more-languages/

https://github.com/microsoft/win32metadata/blob/master/docs/roadmap.md

And from https://kennykerr.ca/2021/01/21/rust-for-windows/

I am excited to finally talk about the grand plan we have been working on for some time, namely the unification of the Windows API. No more Win32 here, WinRT there, COM this, UWP that.

[berhir]

@pjmlp The .NET Conf: Focus on Windows event was recently announced for February 25, 2021. At the end of the description, it says

You'll also see what the future of native device development with .NET will look like in .NET 6.

Will it be about UWP too or only about WPF and WinForms?

[robloo]

I can't help but think this is a step backwards for UWP developers that come from a WPF/C# background. As an example: The text file where native methods are declared is, well, cumbersone and not modern at all. Personally, I think opening up all APIs together will create a mess too. There should at least be separate nugets and an attempt to separate ancient from new API designs.

This is also going to require rewriting all WinRT API signatures in existing code it looks like - along with the changes required for WinUI 3. Note that WinUI 3 is still going to be missing functionality for quite some time. This is quite difficult to stomach as a UWP developer.

[duckheadsoftware]

I wonder what a UWP app will be going forward. The UI will be WinUI, Framework will be .net 6, API will be reunion, which is exactly the same as Win32 apps; the only different a UWP app vs Win32 app will have is the security container. Maybe that's a good thing, I can develop an App and decide if I want to switch on the app container ?

[pjmlp]

From all the information I have been getting from blogs, podcasts and Channel 9 videos, I am assuming the end goal is going back to pre-WinRT development model, integrating the sandbox and COM improvements from UWP world, with .NET 6 AOT being just another deployment opinion, is the long term roadmap for Reunion.

[Noemata]

@pjmlp , thanks for the info. @robloo , I can appreciate the need to evolve and iterate WinUI. I can even appreciate that Microsoft may have decided they got some things wrong with UWP. Having the UI layer require OS updates was a big problem. There was a lot Microsoft got right with UWP (it's a very long list of positives). What hasn't been made clear is whether Microsoft will retain a sandboxed execution context when WinUI is out and how they propose to encourage that style of authoring given many devs will skip the constraints putting the rest of us at a disadvantage. What's going to replace the .Net Native compiler? I've made the point about reverse engineering of code and have yet to get anyone from Microsoft to respond.

Running apps outside of a sandbox is a mess for your average PC user. That's the biggest step backwards I'm concerned about.

@robloo , the major blow to the gut is how the UWP devs now feel dispensable. All this time, we've been drinking the Kool aid in Jonestown, apparently. For the rest of this year I'm going to do my best version of Rasputin. Hope that works out.

[pjmlp]

Regarding .NET 6 AOT, you might want to look into this, https://github.com/dotnet/designs/blob/main/accepted/2020/form-factors.md

[Noemata]

@pjmlp , I'm tempted to provide a more detailed reply here, but it seems we've already ventured way off topic. It's time Github adds a forums like section with a hierarchy so discussions can logically break into other subjects as they evolve during discussions such as this. Any suggestions for a better place to archive this sort of discussion and retain visibility within the UWP community? Particularly for Microsoft.

[Noemata]

I will add one quick note: I did talk to the developers of the Unity engine. They became so frustrated with .Net Native that they started their IL2CPP initiative. Microsoft simply stopped investing in .Net Native as the technical hurdles appeared to become intractable. It wasn't that the technical challenges couldn't be solved ... Microsoft has certain "organizational deficiencies" with the way technically challenging projects evolve over long time periods. Unity will eventually fragment .Net to the peril of .Net. Why? Unity is evolving into a better version of .Net's cross platform promise that's being kept with a vengeance.

[saint4eva]

I can't help but think this is a step backwards for UWP developers that come from a WPF/C# background. As an example: The text file where native methods are declared is, well, cumbersone and not modern at all. Personally, I think opening up all APIs together will create a mess too. There should at least be separate nugets and an attempt to separate ancient from new API designs.

This is also going to require rewriting all WinRT API signatures in existing code it looks like - along with the changes required for WinUI 3. Note that WinUI 3 is still going to be missing functionality for quite some time. This is quite difficult to stomach as a UWP developer.

cswin32 vs cswinrt vs project reunion?

[sukesh-ak]

@pjmlp , I'm tempted to provide a more detailed reply here, but it seems we've already ventured way off topic. It's time Github adds a forums like section with a hierarchy so discussions can logically break into other subjects as they evolve during discussions such as this. Any suggestions for a better place to archive this sort of discussion and retain visibility within the UWP community? Particularly for Microsoft.

Btw, forum like section is already available on top. A relatively new feature on github.