Modernize your UWP app with preview UWP support for .NET 9 and Native AOT

[Duncan MacMichael (duncanmacmichael)]

Hi everyone!

We recently announced preview UWP support for .NET 9, described in detail on the #ifdef Windows blog here: Modernize your UWP app with preview UWP support for .NET 9 and Native AOT. This is an effort to help you with the following:

1. Provide a better upgrade path from UWP to WinUI 3.
   • With preview UWP support for .NET 9, you can upgrade your app incrementally by separating the costs and risks of migrating the .NET runtime from migrating the business logic.
2. Enable you to remove dependencies on .NET Native.
   • .NET Native has slow build times, poor debugging support for issues related to trimming and ahead-of-time compilation, and is becoming harder to support.

🚨 Please use this post to provide community feedback, ask questions, and discuss preview UWP support for .NET 9. 🚨

If you hit any issues while trying it out, use the following channels to report them:

• For CsWinRT-specific issues (such as the WinRT interop failing), use the CsWinRT repo.
• For Microsoft Store- or Parner Center-related issues (such as certification failures), use the Store Discord channel.
• For other issues not related to preview UWP support for .NET 9 itself, use the existing support channels. For example:
  • For issues with existing UWP APIs, use Feedback Hub.
  • For issues related to WinUI 2, file an issue in this repo (the WinUI repo).

Thank you, and we're looking forward to hearing from you!

[Steven Blom (AtomicBlom)]

This is amazing, you've really made my day with this announcement. The application I develop has been stuck waiting for InkCanvas support in WinUI 3, and gradually a few of our libraries have been dropping .net standard 2.0 support, leaving us to maintain our own forks.

I have a small question regarding ARM64 support as I'm using a Surface Pro 11 as my main development machine. The "Project Templates for UWP projects targeting .net 9 and Native AOT" VSIX in the blog doesn't seem to support ARM64 versions of Visual Studio, is there a chance that we'll see support for that in the future?

Additionally, I'm curious to know if the support for .net 9 means that we'll be able to debug on ARM64 natively. At the moment I'm compiling to X64 and it works well, but it would be nice to get rid of the emulation layer if possible, as I can't currently run the app on ARM64 natively without a .NET Native build.

Again, thank you all SO... SO MUCH.

[Steve (hez2010)]

The "Project Templates for UWP projects targeting .net 9 and Native AOT" VSIX in the blog doesn't seem to support ARM64 versions of Visual Studio, is there a chance that we'll see support for that in the future?

Sounds like a template issue. Nothing prevents you from creating the project from scratch or copying the template project created from another device.

I'm curious to know if the support for .net 9 means that we'll be able to debug on ARM64 natively.

Yes.

[Fela (FrayxRulez)]

.NET Native has slow build times

Currently my project builds faster using .NET Native in Release configuration than using .NET 9 with AOT in Debug configuration.
Are optimizations to the CsWinRT code generators already in the work? I'd love to adopt .NET 9 in either UWP or WinUI 3, but this is a complete blocker for me.

[Sergio Pedri (Sergio0694)]

Mmh that doesn't sound right. Are you able to provide a verbose binlog or record a trace? FYI Manodasan Wignarajah (@manodasanW)

[Fela (FrayxRulez)]

Sure, how can I collect them?

[MartyIX]

https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Binary-Log.md#creating-a-binary-log-during-a-build this way I think. That is:

dotnet build /bl

[Fela (FrayxRulez)]

Can't build with dotnet because I have a few vcxproj, but msbuild ... /bl seems to do the trick. Only thing is that it seems to start from scratch every time...

[Sergio Pedri (Sergio0694)]

Fela (@FrayxRulez) can you follow these steps first, and share the resulting .zip? Should be a good place to start. Feel free to DM that on Discord if you don't want to share it here publicly (in case it contains any private info from your machine). Thank you! 🙂

[Carlo Mendoza (myokeeh)]

First, thank you very much!

Note to others: you will need to enable "use previews of .NET SDK" in Visual Studio.

I'm getting an "Operation is not valid due to the current state of the object." error when creating the project from the VS template. I'm not sure if the following issue is because of this error.

App won't build with the following. I tried installing the 8.0.4 System.Text.Json, but can't resolve the error.

NETSDK1060 Error reading assets file: Error loading lock file 'C:\Users\Carlo\source\repos\APP UWP with NET 9 Test 1\APP UWP with NET 9 Test 1\obj\project.assets.json' : Could not load file or assembly 'System.Text.Json, Version=8.0.0.4, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified. APP UWP with NET 9 Test 1 C:\Program Files\dotnet\sdk\9.0.100-rc.2.24466.31\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets 266

[Ursusworks (ursusworks)]

Got me past that error :) A new one popped up though:

Which leads to:

Deploy is checked in Configuration Manager.

I've tried to hunt down the .appx package. But these are usually generated at build and difficult to find. Closest I came was: C++ Runtime v11.0 framework package for Desktop Bridge (Project Centennial)

Also installed Visual Studio 2012 (VC++ 11.0) Update 4. And tried to add it as a dependency in Package.appmanifest.xml. No change though.

[Sergio Pedri (Sergio0694)]

Are you 100% sure you're on VS 17.12 P2, and you've follow exactly all other instructions in the blog post (eg. including that line to exclude WebView2, etc.)? I have not seen this issue before, but it seems like you're missing an SDK reference, which should be added by default in that new preview of VS.

[Ursusworks (ursusworks)]

Hmm. There shouldn't really be any differences with community or enterprise should it when it comes to SDK references?

I can build up a clean VM tomorrow and rebuild the enviroment from scratch.

• By tomorrow, I mean monday...

[Ursusworks (ursusworks)]

Created a fresh VM.

• Installed VS 2022 Community 17.12 Preview 2
• Installed nightly dotnet 9 SDK (dotnet-sdk-9.0.100-rc.2.24468.2)
• swapped out the XAMLCompiler dll and .target file
• set dotnet9 source in %appdata%/nuget/nuget.conf
• Installed templates

I can build the templates on a fresh VM, so something about the problem laying between the keyboard and the chair I guess.

The build process on the VM also required the WindowsSdkPackageVersion to be set in the .csproj file. But the key difference between the VM and my actual computer seems to be the version of Microsoft.VCLibs for UWPDesktop it tries to deploy.

The VM tried to deploy 140.00 and succeeded. My computer tries to deploy 110.00 and fails because the package is missing.