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

[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!

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

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

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

[Sergio0694]

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

[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

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

[Sergio0694]

@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! 🙂

[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

[bear-karlsen]

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.

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

[bear-karlsen]

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

[bear-karlsen]

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.

[Sergio0694]

Did you forget to install the C++/UWP workload/components in VS? I wonder if you're missing 140.00 on your computer.

[quick-gate]

Will it be supported on Xbox?

[Sergio0694]

It's not officially supported at the moment (though it will work fine on Xbox if you try it). If you have specific use cases for why you'd need official support for Xbox, please let us know about them! 🙂

[quick-gate]

I am working on background music player for Xbox, and it would be really nice to use .NET5+ libraries and features. Official support would be great to ensure that all features will be supported on Xbox.

[Doprez]

I would be curious to know what support would look like. Stride was in the process of removing our old implementation of UWP due to it not working for us since we updated to .NET 6.

We have some planned work to create a testing branch of Stride using .NET 9 so getting UWP working again would be pretty cool to test out.

[lhak]

I tried out the preview and it is overall working great! Here are some issues I observe (I use a UWP app + win32 helper with a separate packaging project)

• Strings for localization (resw files) contained in the app project are not accessible from the packaged app. I need to add them via <PRIResource> to the packaging project file.

• I cannot cast the IActivatedEventArgs argument from the OnActivated() method with the c# as keyword but have to use the WinRT function. Example: args as IProtocolActivatedEventArgs does not work, but args.As<IProtocolActivatedEventArgs>() does.

• When OnActivated() is called, the SynchronizationContext is null. I can work around this issue by creating a new DispatcherQueueSynchronizationContext.

[Sergio0694]

Thank you for the feedback!

• Mmh that is interesting. Don't know off the top of my head if this is expected, but we'll look into it.
• That is unexpected, a normal cast should have worked. Can you please log an issue for this in https://github.com/microsoft/CsWinRT with a minimal repro? We would like to understand why that's happening, so an exact code snippet to reproduce would help.
• Are you using the XAML generated main, or did you disable it? The updated XAML compiler will set that synchronization context automatically when creating the app, so that should show up there. If you disabled that, that could explain it.

Update: (thanks to @ahmed605 for the help investigating this), so the resw files not being accessible is actually expected. It worked for UWP previously because in that case both projects were packaging projects, so their resources were automatically combined. Here instead with the .NET 9 tooling, the app project is just a normal .NET project, so the resources are no longer merged automatically. This is the same with a packaged WinUI 3 project, it's not just a UWP .NET 9 issue. It might be interesting to look into adding some support for making this automatic in the future, both for UWP and WinUI 3, but for now yeah this behavior is just by design, and your workaround of adding PRIResource-s for those resw files is correct 🙂

[lhak]

Thank you for the reply. I will file an issue soon for the second problem I observed. Regarding the first issue, I am still not sure if I should enable <EnableMsixTooling> in the UWP app project or not. I observe the following behavior:

EnableMsixTooling enabled

• Accessing resource strings works without adding them to the packaging project.
• I cannot access any images from the app project from XAML using ms-appx:// URIs. The files are copied to the output folder correctly but the resulting resources.pri file does not take into account that all application files are copied to a subfolder when using the packaging project (this differs from UWP) and includes them with the wrong path.

EnableMsixTooling disabled

• Resource strings need to be referenced in the packaging project with <PRIResource>.
• By default the app will not work because the xbf files are missing. They also have to be added to the packaging project.
• Image files can be accessed correctly (they are not referenced in the resources.pri file at all).

[ahmed605]

By default the app will not work because the xbf files are missing. They also have to be added to the packaging project.

Hm this isn't right, did you use the .NET 9 Windows App Packaging template to create the project or the old one? the old one won't work as-is

[lhak]

I tried with a new app from the "Blank UWP App with Windows Application Packaging Project (Preview for .NET 9)" template and when I publish an msix file, the xbf files are not included.

[josephpdowney]

So with the release of RC2 does this process change?

[Sergio0694]

With RC2, you don't need to install a nightly build of the .NET SDK anymore. Also with VS 17.12 P3, you don't need to set "UseUwpTools" in the .csproj anymore, as it's automatic. And you don't need to specify "RuntimeIdentifiers" in libraries anymore.

[IXLLEGACYIXL]

does this mean that UWP is comming back as GDKs account barriere makes it a bad option for xbox support and UWP was fine for that ?

[devsko]

I am currently trying to upgrade a pretty large project to modern UWP. It’s a bit tedious because most referenced UWP packages can’t be used as they are and need to be adjusted locally. Right now, i use local builds amongst others of

• Microsoft.UI.Xaml
• Microsoft.Xaml.Behaviors.Uwp.Managed
• CommunityToolkit Windows and Labs-Windows

So far i recognized several issues (in no particular order)

• a reference to Microsoft.VisualStudio.Threading pulls in WPF and WinForms (it does this also under WinUI3 but without errors). In modern UWP this results in XamlCompiler error WMC1006: Cannot resolve Assembly or Windows Metadata file 'Type universe cannot resolve assembly: System.Windows.Forms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.' (worked around by a local build of vs-threading)
• Several IL2059 warnings for nullable enums i.e. typeof(global::System.Nullable<global::CommunityToolkit.WinUI.Animations.EasingType>) (ignored this for now)
• InvalidCastException when marshalling enumerables of WinRT types to WinRT
  • using Windows.Devices.Geolocation; new Geopath([new BasicGeoposition(0, 0, 0)]);
  • using Windows.UI.Xaml.Controls.Maps; MapStyleSheet.Combine([MapStyleSheet.Aerial(), MapStyleSheet.RoadDark()]); (this i cannot work around)

Overall, the preview does pretty good for what i was waiting for years ❤️. I am still far from getting my project running though.
Please let me know if you need more details.

[Sergio0694]

Thank you for the feedback! 😄

"It’s a bit tedious because most referenced UWP packages can’t be used"

Yeah if you want to use especially those 3, it's a bit annoying. We're working on publishing updated versions of all of them (we already have internal builds for all of them), but we're waiting for some of the tooling to be available in stable release first (especially the XAML compiler, as without that the CI could not run at all on most of those, which is not ideal). But, coming soon!

"a reference to Microsoft.VisualStudio.Threading pulls in WPF and WinForms"

Interesting. Is that package open source? I assume we could perhaps fix that with some .targets tweaks of some sort.

"Several IL2059 warnings for nullable enums"

Yup that's a known issue in .NET 9. You can safely ignore those warnings. I've fixed the issue in the XAML compiler to avoid generating all those unnecessary static constructor stubs entirely. That fix will be available in the final release build soon.

"InvalidCastException when marshalling enumerables of WinRT types to WinRT"

Mmh that might be an issue in CsWinRT (which might very well hit WinUI 3 as well). Could you please open an issue for that at https://github.com/microsoft/CsWinRT, ideally with a minimal repro? The more feedback we get on this kind of thing, the better.

Thank you again, please keep the feedback coming! 🙂

[devsko]

Thanks for your reply. Good news about the updates!

Is that package open source?

It is. https://github.com/microsoft/vs-threading. I mentioned it because of the error after referencing WinForms. You can repro it

• New .NET9 UWP app (+ WindowsSDKPackageVersion). Add:

<Reference Include="System.Windows.Forms" HintPath="C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App\9.0.0-rc.2.24474.4\System.Windows.Forms.dll" />

and the build fails.

I know it makes no sense, but vs-threading does it under the condition $([MSBuild]::IsOSPlatform('Windows')). I'm sure there are a lot of packages that pull some weird references. It should just not fail to build in these cases.

[Sergio0694]

Mh, interesting. I've seen the XAML compiler fail in a similar case before as well (some older WebView2 package was also pulling in WinForms and WPF, and that crashed the compiler). I think it's kinda normal here and the compiler just doesn't expect to see any of those types available. If that Reference is added in a .targets in the package, I assume fixing it should be as simple as doing:

<Reference
  Condition="'$(UseUwpTools)' != 'true''"
  Include="System.Windows.Forms"
  HintPath="...<PATH>...System.Windows.Forms.dll" />

Which we already use in several places. Perhaps you could try making a PR (or at least opening an issue in that repo, for tracking)? Also, just double checking, I assume you already validated that building and running the package without that reference still works as expected and doesn't cause other issues?

[devsko]

InvalidCastException when marshalling enumerables of WinRT types to WinRT

I filed CsWinRT #1839. After recognizing that modern UWP defaults to DynamicCodeSupport=false (in contrast to WinUI3), UWP and WinUI behave the same wrt marshalling when this is switched on. Aside from AOT everything works. That is absolutely amazing!

[devsko]

I want to come back to an issue that @lhak described above: content files of an UWP app are packaged at a different path in a separate wapproj. They moved into an App sub-folder. As a result, all ms-appx paths must be changed - not possible if they are used by 3rd party libraries. The only workaround I could come up with, is to duplicate all content files in the packaging project (including 3rd party content).
Any advice would be nice.

[devsko]

I found the reason for the resource related issues: If there is a packaging project and

• EnableMsixTooling is absent or set to false, the WindowsAppSDK is not referenced at all and the UWP project does not produce a .pri file
• EnableMsixTooling is true, the WindowsAppSDK produces a final resources.pri file for the UWP project that is not picked up by the packaging project.

What is needed is a project.pri to include all .resw and content files in the final resources.pri in the package.
The simple solution:

• setting EnableMsixTooling to false and
• manually adding <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.6.240821007-preview2" IncludeAssets="build" PrivateAssets="all" />.

APPX and MSIX files contain everything they need without any further PRIResource or file duplications. ms-appx URIs work as expected.
@Sergio0694 Sadly, I can not prepare a PR for Microsoft.Windows.UI.Xaml.ModernNET.CSharp.Targets 😊

[Sergio0694]

Thank you for looking into the issue! This matches what @dongle-the-gadget said, and it's on my todo list of things to do. This is going to potentially need more thought, because we're not going to be using WinAppSDK for the UWP support in the final release. At least for now, you have a workaround, so that's great. I'll try a few things out this week and see what a proper solution could be 🙂

[devsko]

This matches what @dongle-the-gadget said

Can you please point me to this?

[andrew-kulikov]

I've followed migrations steps from the article, installed .NET SDK 9.0.200-preview.0.24527.8 and Windows SDK 10.0.26100.1742 and encountered a few issues that I hope you can help address:

1. Build Fails with dotnet build command

   I created an example UWP app that builds and runs successfully in Visual Studio. However, when I attempt to build the same app using the dotnet build, I receive the following errors:

   App.xaml.cs(31,13): error CS0103: The name 'InitializeComponent' does not exist in the current context
   MainPage.xaml.cs(21,9): error CS0103: The name 'InitializeComponent' does not exist in the current context
   

   It appears that the InitializeComponent method is not being generated or recognized during the command-line build process. Is there a known issue or a workaround for this discrepancy between Visual Studio and dotnet build?

2. Issue with Externally Defined Application Class

   In our project, we have a base library shared across multiple applications. This library declares a custom Application class that inherits from Windows.UI.Xaml.Application, which we consume via Application.Start. When I try to launch an app that references this externally defined Application class, it fails to run with error:

   Unhandled exception at 0x616EC671 (Windows.UI.Xaml.dll) in Example.Uwp.Net.exe: 0xC000027B: An application-internal exception has occurred (parameters: 0x1126A4E0, 0x00000002).

   Interestingly, if I copy the Application class directly into the app project (ensuring all XAML-related code is generated), everything works as expected. Is there a way to use the externally defined Application class without duplicating the code in each application?

3. Consuming NuGet Packages with .winmd Files Results in Runtime Error

   I'm attempting to consume a NuGet package that contains .winmd files. Following the tutorial on Creating a .NET Projection from a C++/WinRT Component, I created a WinRT projection of the library. However, the app fails at runtime with the following error:

   System.Runtime.InteropServices.COMException: 'Class not registered (0x80040154 (REGDB_E_CLASSNOTREG))'
   

   Do you have any guidance on how to successfully consume such a NuGet package in a UWP application on .NET 9 without encountering this runtime error?

4. Accessing SoftwareBitmap Pixel Data

   In our project, we use BitmapDecoder to obtain a SoftwareBitmap and then pass a pointer to its pixel data to a native library. Previously, we could cast the IMemoryBufferReference obtained from SoftwareBitmap.LockBuffer to IMemoryBufferByteAccess to access the pixel buffer, as described in the Microsoft documentation on Imaging.

   However, with AOT compilation enabled in .NET 9, this approach no longer works, and we haven't found an alternative solution. The only workaround we've discovered is to manually calculate the offset in the object's memory to retrieve the pointer:

   var nativeReference = ((WinRT.IWinRTObject)_memoryBufferReference).NativeObject.ThisPtr;
   var byteBuffer = Marshal.ReadIntPtr(nativeReference, IntPtr.Size * 10);

   Is this a viable and safe solution, or is there a more straightforward method to access the pixel data? Could we, for example, obtain the necessary COM interface differently or use another decoder?

[dongle-the-gadget]

1. dotnet build uses MSBuild Core, whereas Visual Studio uses MSBuild Framework. UWP only supports MSBuild Framework.
2. My guess would probably be an .xbf error, but I can't say for sure without the rest of the error message.
3. You need to copy the WinMD to build output, CsWinRT doesn't do that for you.
4. WindowsRuntimeMarshal.TryGetDataUnsafe. Make sure to keep your reference alive while using the data pointer returned using GC.KeepAlive, or copy the data to another memory address that you can control.