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.

[mesta1]

I also am stuck on UWP mostly for XBox support.

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

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

[AArnott]

after referencing WinForms...
...but vs-threading does it under the condition...

The vs-threading package has this in the nuspec file:

    <frameworkReferences>
      <group targetFramework="net6.0" />
      <group targetFramework="net6.0-windows7.0">
        <frameworkReference name="Microsoft.WindowsDesktop.App.WPF" />
      </group>
      <group targetFramework=".NETFramework4.7.2" />
      <group targetFramework=".NETStandard2.0" />
    </frameworkReferences>

The threading library has API that exposes WPF types, so on runtimes that support WPF, it necessarily references it.
I can't find any evidence of System.Windows.Forms references though.

If the XAML compiler crashes when a project references a WPF assembly, that sounds like it's worth a distinct bug against the xaml compiler.

[Sergio0694]

That's expected, and the issue is that NuGet package is malformed. Even if it didn't crash the XAML compiler, bringing WPF references would still cause a ton of problems for NativeAOT. It's just incorrect to pull in UI framework dependent binaries based on TFM. The official recommendation is to have separate NuGet package per UI framework. Alternatively, you could have a .targets in the NuGet package that conditionally adds a reference to a WPF-specific .dll if some property is set. But unconditionally doing so like this is just a recipe for errors. For instance, System.Reactive also has the same issue, which makes it basically unusable with NativeAOT without hacks.

[AArnott]

I'm curious whether such "incorrect" patterns are documented as such anyway.

Regardless, it wasn't really a choice we had. vs-threading existed long before .NET did. And on .NET Framework, adding a WPF dependency was a non-issue. And as our WPF dependency is mixed into the same class as non-WPF dependencies in the library, we cannot simply move the class out into its own assembly. For binary compatibility then, we are required to have a WPF dependency in the threading library for net8.0-windows.

[devsko]

The compiler issue seems to be fixed in VS 17.14 Preview 1 (I did not try 17.13 rtm)

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

[MattBDev]

• dotnet build uses MSBuild Core, whereas Visual Studio uses MSBuild Framework. UWP only supports MSBuild Framework.

@dongle-the-gadget @Sergio0694 Is there any solution to this? I was hoping to use Visual Studio Code to build my app.

[Sergio0694]

There are no plans to change that. Building UWP apps requires MSBuild Desktop, that's just by design. That said, you should be able to also configure VS Code to build your project, as long as you make it use a VS Developer Command Prompt as the terminal used for building, and you make it use msbuild from there (instead of dotnet build).

But if you wanted to be able to just have VS Code installed and not VS at all, then no that's never going to work 😅

[Micro666]

Hi,

I work for a company where we have created a line of business UWP app (not in the Store) over the last 7 years. Just the other day we were discussing the process for moving from UWP to an app developed with WindowsApp SDK, and all the issues that would entail.

This new UWP for .Net 9 project has come at just the right time for us, as it will provide a more step by step approach to migration, allowing us to migrate firstly to .Net 9, then to WinUI3, and finally to the full Win32 model.

I've installed VS2022 17.12 Preview 5 and all .Net Desktop and Windows App development components, the latest Windows 11 SDK version 10.0.26100.1742, and also the VSIX for the templates.

On creating a new UWP for .Net 9 project, I'm getting the following error on build:

Microsoft.UI.Xaml.Markup.winmd cannot be referenced. Referencing a Windows Metadata component directly when targeting .NET 5 or higher is not supported. For more information, see https://aka.ms/netsdk1130

This is literally from creation of a new project. No changes made at all. I've rebooted, double checked the installed VS2022 17.12 Preview components, all is as it should be.

Can anyone help diagnose or help fix this issue?

These are the dependencies that are added by default:

I notice that under Packages, the SDK BuildTools are version 10.0.22621, is that correct? Is this the same version that everyone else has?
Thx

[Sergio0694]

Did you follow the steps in the blog post to download and patch the XAML compiler? If not, that error is expected.

[Micro666]

Edit: I've patched the XAML compiler. All working

Ah no, as when I read the following in the blog post You’ll also need an updated version of the XAML compiler that supports .NET 9 projects. This will be included in an upcoming servicing release of the Windows 11 SDK (10.0.26100.0) I assumed (wrongly I guess) that because I was installing Windows 11 SDK 10.0.26100.1742, a later version than specified, that it included the updated XAML compiler.

Thx for getting back to me so quickly Sergio.

I'm very happy that you've created this new toolset, as it will be a life saver for us, to be able to migrate our now approximately 7 years in development, UWP enterprise app. A pretty large app as well, as we had to move off of AppCenter for building as we "broke" the 4GB limit during compilation.

Is the intention for developers with existing apps to be able to re-target / edit their existing projects in order to convert them into UWP for .Net 9 projects, or is the intention that in such use cases, a developer with an existing app, should ideally create a brand new blank UWP for .Net 9 project/solution, and migrate C# code and XAML over manually from the existing to the new project?

Our project is very large, with a lot of projects/files. I'm hoping I can "convert" the existing projects, and then deal with the issues that arise, as to manually move everything over to a new project/solution whilst possible, will be a lot more involved.

Either way, this is a great new feature that I'm excited exists!!

[Sergio0694]

Glad to hear this will be useful for you, that's great to hear! 🙂

"Is the intention for developers with existing apps to be able to re-target / edit their existing projects in order to convert them into UWP for .Net 9 projects, or is the intention that in such use cases, a developer with an existing app, should ideally create a brand new blank UWP for .Net 9 project/solution, and migrate C# code and XAML over manually from the existing to the new project?"

You cannot multi-target existing projects, as the build infrastructure is completely different for .NET 9 projects. What I would personally recommend is to create a new project right next to the old one (ie. in the same folder). You can imagine something like:

\ MyApp
    App.xaml
    App.xaml.cs
    App.appxmanifest
    MyApp.csproj
    MyApp2.csproj <-- NEW FILE

That "MyApp2.csproj" file is a .csproj with the new UWP .NET 9 stuff. Because it's an SDK-style project, it will automatically import all files from its directory, meaning in VS you'll just see all files being shared with it like you would expect. This allows you to literally just create one project file to migrate an entire project, while fully sharing code. If you then need to do any specific changes to the code for modern .NET, you can easily do stuff like #if NET9_0 in C# to switch between this and the old UWP project. This is the same approach I'm using to migrate the Microsoft Store, for instance. It requires minimal work and it's quite convenient 🙂

Hope this helps!

[Micro666]

Actually that's even better than I was hoping, as originally I was hoping to just go through and "convert" all existing projects in the solution with the new project structure, along with re-targetting to .Net 9, and the new SDK.

Your proposed solution, and the one which you are using yourself on the Microsoft Store, having both old UWP .csproj files, and new UWP .Net 9 .csproj files side by side, with code sharing of the .cs files etc, is perfect, especially as I can also use conditional compilation as you mention, to handle cases where I need to do something different in the .Net 9 build

Many Thx!!

[Micro666]

First stumbling block, converting one of our class libraries, in our large UWP app, is that is uses the following nuGet package:

Microsoft.UI.Xaml.Behaviors.Uwp.Managed

However this cannot be installed in a UWP for .Net 9 class library, as it says it's not compatible with .Net 9.

An alternative I could use is the following nuGet package:

CommunityToolKit.UWP.Behaviors

However, whilst that installs, it causes the following error:

The type or namespace name 'Xaml' does not exist in the namespace 'Uno.UI' (are you missing an assembly reference?)

as it seems that the package is dependent on the Uno.UI package, which is listed in the package manifest as a .net 8 dependency. Installing the Uni.UI nuget package manually, just results is many more errors :-(

I guess this are the kinds of issues that are going to crop up as people migrate their UWP apps. It's not the fault of the nuGet package developers that they don't support .Net 9, nor that they for some reason have a dependency on the Uno.UI nuGet package, which is very incompatible with UWP for .Net 9

Other than stripping out functionality from our UWP app, that relies on XAML behaviors, I'm not sure how I can make this functionality work.

[Sergio0694]

This is expected, we haven't shipped the new versions of those packages yet. You'll be missing:

• WinUI 2
• XamlBehaviors
• Windows Community Toolkit (all packages)

We're working on it, and we'll try to publish public previews/releases soon.
However until we do, yeah you won't be able to migrate code using them 🥲

[Micro666]

Again, thx for the quick reply. That's great the issue I'm encountering is expected, and it's great to know that these will be addressed as part of future planned work.

I certainly didn't expect my first attempt to convert one if it libraries to 'just work'. This is a preview after all, and it's all about finding what works, what doesn't work etc.

I'll try converting other libraries to see if I encounter any other issues, and raise anything relevant here.

Many thx

[MagicAndre1981]

Now that .NET9 is released how should we start? Will the Upgrade Assistant be updated to include the new UWP project format? Or do we have to create a new project on our own and copy the files to the new project?

[Sergio0694]

Now that VS 17.12 and .NET 9 are out in stable, that means you have access to the preview tooling for UWP without the need to install other components other than those two. You can manually add a reference to Microsoft.Windows.SDK.CPP version 10.0.26100.2161 to avoid having to manually patch your XAML compiler locally. Note that WinUI 2 and Windows Community Toolkit are still work in progress and not publicly available yet.

[MagicAndre1981]

ok, so I'll wait a bit

[Noemata]

Have seen a dramatic improvement in all things related to UWP and WinUI since Sergio has been in the picture. Thank you!

[Noemata]

Just tried to create a UWP project with .net 9 and the latest VS release.

Microsoft.UI.Xaml.Markup.winmd cannot be referenced. Referencing a Windows Metadata component directly when targeting .NET 5 or higher is not supported. For more information, see https://aka.ms/netsdk1130

Which version of this should be used??

<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.6.xxx" IncludeAssets="build" PrivateAssets="all" />

Is the nuget.config change still required?

Never mind, I didn't realize I needed to leave the SDK version at the latest. Works!

[Sergio0694]

You forgot to patch the XAML compiler. You also shouldn't be using WindowsAppSDK at all, that's for WinUI 3. I have the instructions for this in the blog post, with a link to the XAML compiler patch. Alternatively you can add a reference to Microsoft.Windows.SDK.CPP version 10.0.26100.2161 to avoid having to manually patch your XAML compiler locally. The nuget.config change isn't needed.

[Noemata]

Got all this wrong. Picked the wrong starting template. Starting over.

[Noemata]

Working steps with latest of everything are:

Install Visual Studio 2022 version 17.12.0, install .Net 9 SDK, install UWP .Net 9 support VSIX, select this template

select this target version

add this to your project file

  <ItemGroup>
    <PackageReference Include="Microsoft.Windows.SDK.CPP" Version="10.0.26100.2161" />
  </ItemGroup>

So you wind up with this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net9.0-windows10.0.26100.0</TargetFramework>
    <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
    <UseUwp>true</UseUwp>
    <UseUwpTools>true</UseUwpTools>
    <Platforms>x86;x64;arm64</Platforms>
    <RuntimeIdentifiers>win-x86;win-x64;win-arm64</RuntimeIdentifiers>
    <DefaultLanguage>en-US</DefaultLanguage>
    <PublishAot>true</PublishAot>
    <PublishProfile>win-$(Platform).pubxml</PublishProfile>
    <DisableRuntimeMarshalling>true</DisableRuntimeMarshalling>
    <EnableMsixTooling>true</EnableMsixTooling>
  </PropertyGroup>
  <ItemGroup>
    <ApplicationDefinition Update="App.xaml">
      <SubType>Designer</SubType>
    </ApplicationDefinition>
  </ItemGroup>
  <ItemGroup>
	<ApplicationDefinition Update="App.xaml">
		<SubType>Designer</SubType>
	</ApplicationDefinition>
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Windows.SDK.CPP" Version="10.0.26100.2161" />
  </ItemGroup>
  <ItemGroup>
    <ApplicationDefinition Update="App.xaml">
      <SubType>Designer</SubType>
    </ApplicationDefinition>
  </ItemGroup>
  <ItemGroup>
    <Page Update="MainPage.xaml">
      <SubType>Designer</SubType>
    </Page>
  </ItemGroup>
</Project>

[Sergio0694]

FYI you can remove:

• "UseUwpTools", not needed
• All those "ItemGroup"-s for XAML files (VS incorrectly adds them, but they're unnecessary)

[Noemata]

@Sergio0694 , thank you very much. Was just describing a working, mostly out of the box, experience. Presumably, a new VSIX will clean some of this up in the short term. Hopefully, we'll see a UWP .Net 9 designer before too long. Yes, that includes a WinUI designer. I do appreciate the fact that things are looking much more professional again. The last WinUI community call looked pretty good. I opted out of all of this for almost two years because of where UWP/WinUI appeared to be headed. Nice work Sergio. Also really like what you contributed in your private repo. Perhaps some more updated bits could be added there.

[Noemata]

Didn't have a chance to post this yesterday, so here's the cleaned corrected project file. Could we please have CsWinRTAotWarningLevel default to 2, or include it in the generated projects so we can bring it to 0 or 1 as needed.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net9.0-windows10.0.26100.0</TargetFramework>
    <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
    <UseUwp>true</UseUwp>
    <Platforms>x86;x64;arm64</Platforms>
    <RuntimeIdentifiers>win-x86;win-x64;win-arm64</RuntimeIdentifiers>
    <DefaultLanguage>en-US</DefaultLanguage>
    <PublishAot>true</PublishAot>
    <PublishProfile>win-$(Platform).pubxml</PublishProfile>
    <DisableRuntimeMarshalling>true</DisableRuntimeMarshalling>
    <EnableMsixTooling>true</EnableMsixTooling>
	<CsWinRTAotWarningLevel>2</CsWinRTAotWarningLevel>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Windows.SDK.CPP" Version="10.0.26100.2161" />
  </ItemGroup>	
</Project>

When can we expect correct project generation (no extra junk) from VS 2022? Would be nice to open source the VSIX so the community can help itself as needed. It's not needed to open source things with sync expectations, some of us like to fork our variants for internal use, while you folks continue to do your thing. Lastly, I'm unclear about how XamlBehaviors will play along with AOT since it's been moved to a "managed" only build? Would be helpful to get some additional guidance around AOT considerations. Especially with options like AllowUnsafeBlocks.

[joellyons]

Now that it's been over eight months since the last blog post about the preview .NET 9 support for UWP, I assume we no longer need to install anything special, as long as we have the latest version of VS, the appropriate workloads, and create a new project using the right template? Should we be using the templates that now ship with VS with names such as "UWP Blank App", etc. (those that do NOT include ".NET Native")?

[Sergio0694]

Correct, everything is in GA now and fully supported. Just install VS and use the built-in templates and you're good to go 🙂

[joellyons]

We have a UWP HoloLens 2 application that doesn't use any XAML (UI is created with DirectX). I'm attempting to migrate it to .NET 9 using the techniques described above. I've started by adding a new project to the existing folder using the "UWP Blank CoreApplication App" template and now I'm working through the problems one-by-one. So far, so good!
As I'm troubleshooting problems, should I think of my new app as a .NET 9 application that acts like a UWP app? Or a UWP application that can access some .NET 9 features?
For example, should I still be able to reference UWP libraries and nuget packages directly (as a UWP app could), or do I need to wrap them as described here because my app is now a .NET 9 app?
Similarly (I think), should I expect to have problems calling some WinRT APIs as explained here? Or am I doing something else wrong?
Thank you!

[Sergio0694]

"I've started by adding a new project to the existing folder using the "UWP Blank CoreApplication App" template and now I'm working through the problems one-by-one. So far, so good!"

That's awesome! Really happy that new template is being useful 😄

" should I think of my new app as a .NET 9 application that acts like a UWP app? Or a UWP application that can access some .NET 9 features?"

Your app is a .NET 9 app, which also uses the UWP app model, and the UWP XAML framework for its UI. It's all of those things 🙂
It's the same as if you had a .NET 9 WPF app, you'd have a .NET 9 app, which uses the WPF framework for its UI.

"should I still be able to reference UWP libraries and nuget packages directly (as a UWP app could), or do I need to wrap them as described here because my app is now a .NET 9 app?"

It depends what you're talking about:

• For WinRT components (eg. Win2D), you'll need them to be updated to use the new .NET projections. Eg. Win2D is updated already.
• For UWP class libraries (eg. the Windows Community Toolkit), you'll need them to be updated to target .NET 9 as well. Eg. the Windows Community Toolkit is also already updated to multi-target .NET 9 as well for UWP.

"should I expect to have problems calling some WinRT APIs as explained here?"

Those docs only say that those APIs won't work in traditional Desktop apps (as in, Win32 apps). They work fine on UWP.

[joellyons]

That helps - thank you!

"should I expect to have problems calling some WinRT APIs as explained here?"
Those docs only say that those APIs won't work in traditional Desktop apps (as in, Win32 apps). They work fine on UWP.

Ok, I must be misunderstanding something - I'll dig in some more

[joellyons]

Ah, some static "GetForCurrentView" calls (such as SpatialInteractionManager.GetForCurrentView) were returning 0x80070490 (Element Not Found). Looking around the web, that lead me to this page. But, as you pointed out, that doesn't really apply here. Digging deeper, that error can also mean there's no CoreWindow assigned to the current thread. Now I realize that some of my migrated code is running on different threads than it did under the "old UWP" because now there's no SynchronizationContext early in the IFrameworkView lifetime, where there was before.
My new project was created using the "UWP Blank CoreApplication App" template. (My existing project was created years ago using who-knows-what template). Would you expect there to be no SynchronizationContext available and I should just create one at some point?

[Sergio0694]

You'll need to manually register it, yeah. You can copy the code for it that the XAML compiler is creating in a UWP XAML app 🙂

[ChristopheLav]

Hi 👋

I have done some tests with the new .NET 9 support for UWP and all seems to be working nicely except the background tasks.

I have test a lot of things based on available peace of documentation here and here without success. I have create a very small test project. Someone has succeed to use one background task with the new tooling? There is some guidance somewhere ?

I see the Microsoft Store app (preview) is using a lot of tasks and has been migrated to .NET 9, so I think I miss something.

Thank you for your help.

BkgTaskDemo.zip

[Sergio0694]

Your setup seems right, I think you're just missing this option in your app .csproj:

<CsWinRTMergeReferencedActivationFactories>true</CsWinRTMergeReferencedActivationFactories>

You'll also need CsWinRT 2.3 (as it has some additional support needed for this), but we haven't release it yet.

So basically until then, background tasks can't work, but you're not doing anything wrong.

[ChristopheLav]

Thank you Sergio!

Have you an idea for the release timeframe of CsWinRT 2.3 ? Possibility of a preview ?

[Sergio0694]

I'd like to release it sometime in May, for sure at least a preview. I'll see if we can get something out soon-ish 🙂

[ChristopheLav]

@Sergio0694 Any news on the CsWinRT 2.3 Preview or GA release ? I expected some news around MS Build but I see nothing (or I missed). Even a preview will allows us to continue to work on the subject 🙂

[Sergio0694]

We're trying to get a preview build out next week, if things line up 🙂

[joellyons]

I've converted our old UWP (HoloLens) app to .NET 9 (UWP) using the latest tools and the tips in this discussion. I did it by creating a new project in the same folder using the "UWP Blank CoreApplication App" template and then tweaking a few things related to COM/WinRT interop. We can deploy it to the HoloLens and run and debug it. This is awesome - thank you!

We've been sideloading our old UWP app from a website for months. Our yaml pipeline (in Azure DevOps) runs the following command:

msbuild.exe "C:\agent2_work\8\s\XR.sln" /bl /t:holo_immersive_net /p:SignCode=false /p:AppxBundlePlatforms="ARM64" /p:AppxPackageDir="C:\agent2_work\8\a\Packages\HoloImmersiveNet" /p:AppxBundle=Always /p:AppxPackageSigningEnabled=false /p:UapAppxPackageBuildMode=SideloadOnly /p:GenerateAppInstallerFile=true /p:AppInstallerUri= /p:platform="ARM64" /p:configuration="Release"

(we sign it later)

Now, this command succeeds but there is no MSIX, etc. output to the "C:\agent2_work\8\a\Packages\HoloImmersiveNet" folder like there used to be. I'm assuming this has something to do with how projects and targets have changed since good ol' UWP, but I'm not sure what. I apologize for my ignorance. Is it expected that I'd need to change something MSIX/AppX related after converting my UWP project to .NET 9?

Note: there was a warning in the pipeline build log, but I'm assuming it's not related to MSIX packaging...

C:\agent2_work_tool\dotnet\sdk\9.0.200\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(323,5): warning NETSDK1206: Found version-specific or distribution-specific runtime identifier(s): alpine-x64, win10-arm, win10-arm64, win10-x64, win10-x86. Affected libraries: Microsoft.MixedReality.QR, Microsoft.VCRTForwarders.140, SQLitePCLRaw.lib.e_sqlite3. In .NET 8.0 and higher, assets for version-specific and distribution-specific runtime identifiers will not be found by default. See https://aka.ms/dotnet/rid-usage for details.

[Sergio0694]

You need to set GenerateAppxPackageOnBuild in the app project to have it produce an .msix/.msixbundle file 🙂

"there was a warning in the pipeline build log"

That package needs to be updated to stop using win10- runtime identifiers, and use win- instead.

[joellyons]

Thank you! I updated the msbuild call to include /p:GenerateAppxPackageOnBuild, but that caused this error:

C:\Program Files\dotnet\sdk\9.0.203\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(214,11): error MSB40
06: There is a circular dependency in the target dependency graph involving target "Build". Since "GenerateNuspec" has "Dep
endsOn" dependence on "Build", the circular is "Build<-GenerateNuspec<-Pack<-PrepareForRun<-CoreBuild<-Build".

Digging through the build log, we noticed setting UseUwp=true causes UseUwpTools to become true, which we assume triggers the "pack" target in some of our projects, which we don't want in this case. Setting UseUwpTools explicitly to false in the csproj fixes the circular dependency error and the MSIX generates successfully.

Here's the project hierarchy...
App (.NET 9 with UseUwp=true and EnableXamlCompilerTargetsForUwpApps=false)
-- Library (.NET 9 with UseUwp=true)
---- Dependency (.NET Standard and includes a pack target, but we're currently just using a project reference)

Setting UseUwpTools to false in the Library project fixes the target circular dependency. Is this expected or are we doing something wrong?

[Sergio0694]

Yes, that's why I said to only enable it in the app project that should produce the MSIX file 😄
Don't just pass it to msbuild unconditionally when building the solution, or you'll get that error.

[joellyons]

Ah! ok, thank you for the clarification. I'm sorry I missed that detail.

[dicksonkimeu]

Will .net 10 have any improvements for uwp support ?

[Sergio0694]

Not sure what you mean, do you have any examples of things you're like to be improved? UWP will get .NET 10 support etc. like any other UI framework as well, so all those improvements will just be there automatically. There isn't anything specific for UWP there.

[dicksonkimeu]

@Sergio0694 Thank you for the good work.

We are planning to upgrade a big UWP app to .net 9. It has background services, we are not sure how they will be affected.

Secondly, the project is layered (mvvm) with .net standard, should update this .net standard targeting to .net 9 ?

[Sergio0694]

"It has background services, we are not sure how they will be affected."

That's supported, but you'll need to wait for CsWinRT 2.3 to get those to work (you need this and this).

"should update this .net standard targeting to .net 9 ?"

Yes, that's recommended to make things AOT-safe. You might actually want to target net9.0-windows10.0.XXXX.0 directly.

[myokeeh]

@Sergio0694, are you able to weigh in on this topic of maybe reinstating support for UWP? https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/ 5144

Based on one of the response from austinbhale, maybe allowing it to work with UWP is not too difficult? I attempted to build what he linked, but I wasn't successful.

I think MSAL is the only blocker for my conversion.

[myokeeh]

I was finally able to build the changes by austinbhale. I ran into "value does not fall within expected range" exceptions and had to put in <PublishAot>false</PublishAot> my csproj file.

[dicksonkimeu]

When is the CsWinRT 2.3 GA Date ?

…

On Tue, 6 May 2025, 09:23 Sergio Pedri, ***@***.***> wrote: "It has background services, we are not sure how they will be affected." That's supported, but you'll need to wait for CsWinRT 2.3 to get those to work (you need this <microsoft/CsWinRT#1637> and this <microsoft/CsWinRT#1895>). "should update this .net standard targeting to .net 9 ?" Yes, that's recommended to make things AOT-safe. You might actually want to target net9.0-windows10.0.XXXX.0 directly. — Reply to this email directly, view it on GitHub <#9983 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCE7FRYUKOIFO2CDBMG63L25BIMNAVCNFSM6AAAAABOEIYBJWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMBUGY3TSMA> . You are receiving this because you commented.Message ID: <microsoft/microsoft-ui-xaml/repo-discussions/9983/comments/13046790@ github.com>

[pfresnay]

@Sergio0694 Thanks for all your great job regarding UWP+NET9 support!

I'm currently migrating a large app and i'm facing an issue in RELEASE mode: app works fine in DEBUG but in RELEASE mode all XAML binding raise exception:

NotSupportedException($"ICustomProperty support used by XAML binding for type '{obj.GetType()}' (property '{text}') requires the type to marked with 'WinRT.GeneratedBindableCustomPropertyAttribute'. If this is a built-in type or a type that can't be marked, a wrapper type should be used around it that is marked to enable this support.");

App use regular MVVM pattern and exception is raised for every viewmodels property access. Adding this undocumented GeneratedBindableCustomProperty attribute seems to solve issue but it's quite strange that I need to add it everywhere.

Am I missing something?

[MartinRichards23]

@Sergio0694 Thanks for all your great job regarding UWP+NET9 support!

I'm currently migrating a large app and i'm facing an issue in RELEASE mode: app works fine in DEBUG but in RELEASE mode all XAML binding raise exception:

NotSupportedException($"ICustomProperty support used by XAML binding for type '{obj.GetType()}' (property '{text}') requires the type to marked with 'WinRT.GeneratedBindableCustomPropertyAttribute'. If this is a built-in type or a type that can't be marked, a wrapper type should be used around it that is marked to enable this support.");

App use regular MVVM pattern and exception is raised for every viewmodels property access. Adding this undocumented GeneratedBindableCustomProperty attribute seems to solve issue but it's quite strange that I need to add it everywhere.

Am I missing something?

Are you using {Binding ... } ? Use {x:bind ... } instead.

[pfresnay]

@MartinRichards23 thanks for quick reply! I'm mostly using x:bind and a few Binding. I commented Binding but still facing issue.

[pfresnay]

@MartinRichards23 You're right, issue is directly related to {Binding}. Thanks!

[TiberiusDRAIG]

@Sergio0694 & @duncanmacmichael: I have a quick question before I dive down the rabbit hole - does UWP on .NET 9 work with the 'Kiosk Mode' functionality in Windows, specifically the single-app kiosk using Assigned Access? UWP has a nifty and super-secure approach to displaying UI above the lock-screen for kiosk apps using the windows.aboveLockScreen capability that is entirely unavailable through any other framework, ensuring that there's no way for a user to 'break-out' of the kiosk to access the underlying machine.

My concern is that this might be wrapped-up in .NET Native and WinUI 2, so before I go ahead and burn a bunch of time diving into this I figured I'd ask here. Otherwise, we're in a position where we'd be building a brand-new UWP app on .NET Native, with polyfils for our modern .NET dependencies, which I'd like to avoid if we can use modern .NET.

Some links for reference:

• Kiosk-mode & Assigned Access: https://learn.microsoft.com/en-us/windows/configuration/kiosk/
• UWP Kiosk apps best practices: https://learn.microsoft.com/en-us/windows-hardware/drivers/partnerapps/create-a-kiosk-app-for-assigned-access
  • UWP Kiosk app with windows.aboveLockScreen capability: https://learn.microsoft.com/en-us/windows-hardware/drivers/partnerapps/create-a-kiosk-app-for-assigned-access#multiple-views-windows-and-threads

[dongle-the-gadget]

Yes it'll work. It doesn't care what runtime you use as long as it's UWP.

[TiberiusDRAIG]

Yes it'll work. It doesn't care what runtime you use as long as it's UWP.

Great, thanks! Just to be clear, it's happy to render WinUI 3 in this way and doesn't rely on platform hooks in WinUI 2 to achieve the dual view stuff? If so, I'm a very happy chappy!

[dongle-the-gadget]

UWP .NET 9 uses WinUI 2 though, not 3

[TiberiusDRAIG]

UWP .NET 9 uses WinUI 2 though, not 3

Ah, cool - misunderstood that bit. Can you tell I haven't gone into detail on this yet? 😅

Thanks for the help - will do a deep dive on this next since it sounds viable.

[DmitryProskurin]

I wan't migrate UWP app with some out of support libraries(like MVVMLight), third party libraries target to .NET Standard 2.1 or libraries target to UAP 10.0.17763. Could there be any problems with third party libraries not being built with .NET 9 support?

[dongle-the-gadget]

UAP libraries won't work. NS2.1 shouldn't be a problem though unless it's not AOT compatible.

[Sergio0694]

"like MVVMLight"

Also note that MVVMLight is deprecated, and the recommendation is to use the Microsoft MVVM Toolkit 🙂

[DmitryProskurin]

@dongle-the-gadget thanks!
@Sergio0694, i think, i will migrate to MVVM Tookit sometime)

I read the discussion and saw that some people have problems with Binding. I read documentation about GeneratedBindableCustomProperty.
Some of SolidColorBrush in my Styles.xaml has Binding(Color property) to properties of singleton class. I use it to support several themes and dynamic switch between them.
Can i use GeneratedBindableCustomProperty on that class to save Binding or I'll have to redo everything on x:Bind?

[pfresnay]

I reproduced a basic but very annoying issue with ItemsControl/ItemsRepeater: if you try to set ItemsSource with non basic IEnumerable, a "value does not fall within expected range" exception occured when PublishAot is activated.

I'm using 9.0.300-preview.0.25177.5 SDK (latest VS Preview)

  <Grid>
      <ItemsControl x:Name="itemsControl"/>
  </Grid>

public MainPage()
{
    InitializeComponent();
    itemsControl.ItemsSource = Enumerable.Empty<string>(); //KO
    //itemsControl.ItemsSource = new string[0]; // OK
}

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net9.0-windows10.0.26100.0</TargetFramework>
    <TargetPlatformMinVersion>10.0.18362.0</TargetPlatformMinVersion>
    <Nullable>enable</Nullable>
    <UseUwp>true</UseUwp>
    <Platforms>x86;x64;arm64</Platforms>
    <RuntimeIdentifiers>win-x86;win-x64;win-arm64</RuntimeIdentifiers>
    <DefaultLanguage>fr-FR</DefaultLanguage>
    <PublishAot>true</PublishAot>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <DisableRuntimeMarshalling>true</DisableRuntimeMarshalling>
    <EnableMsixTooling>true</EnableMsixTooling>
  </PropertyGroup>
</Project>

IssueNativeAOT.zip

[quick-gate]

Binding to IList<> also results in the error "Value does not fall within the expected range."

ListView.ItemsSource = Items....

For example:

• IList<> Items { get; set; } = new List<>(); - Error
• List<> Items { get; set; } = new List<>(); - OK

[Sergio0694]

Do you have AllowUnsafeBlocks=true set in your .csproj file? If you don't, that's usually why this error happens.

[quick-gate]

Yes, I have. <AllowUnsafeBlocks>true</AllowUnsafeBlocks>

Now I see that the issue occurs when the model is in a separate .NET9 library. I tried adding <AllowUnsafeBlocks>true</AllowUnsafeBlocks> to the library's .csproj file, but it had no effect.

[Sergio0694]

What TFM is that library being built for? Is it just net9,0? If so, that won't work. It has to target a Windows TFM.

[quick-gate]

This is a library .csproj

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net9.0-windows10.0.26100.0</TargetFramework>
<TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
<Nullable>enable</Nullable>
<UseUwp>true</UseUwp>
<DefaultLanguage>en-US</DefaultLanguage>
<IsAotCompatible>true</IsAotCompatible>
<DisableRuntimeMarshalling>true</DisableRuntimeMarshalling>
</PropertyGroup>
</Project>

When I set PublishAot=false in the main UWP project, the application works.

[sh0ckj0ckey]

Hello 😀, I'm developing a UWP application using .NET 9 with NativeAOT. When I try to publish the project, I get the following error:

D:\Documents\.nuget\packages\microsoft.dotnet.ilcompiler\9.0.4\build\Microsoft.NETCore.Native.Publish.targets(80,5): error : Overriding System.Private.CoreLib.dll with a newer version is not supported. Attempted to use D:\Documents\.nuget\packages\microsoft.netcore.app.runtime.win-x64\9.0.5\runtimes\win-x64\lib\net9.0\System.Private.CoreLib.dll instead of D:\Documents\.nuget\packages\runtime.win-x64.microsoft.dotnet.ilcompiler\9.0.4\sdk\System.Private.CoreLib.dll.

I do not explicitly reference System.Private.CoreLib.dll in my project. However, I noticed that my project implicitly references:

Microsoft.DotNet.ILCompiler version 9.0.4

Microsoft.NET.ILLink.Tasks version 9.0.5

Both are SDK-implicit references, and NuGet UI says their versions are determined by the SDK and cannot be changed manually. Could the error above be caused by these two implicitly referenced packages, since their versions (9.0.4 and 9.0.5) exactly match the versions mentioned in the error message? If so, how can I resolve this issue? Any help would be greatly appreciated!

For reference, the full project source code is available here

[dongle-the-gadget]

Does clearing the NuGet cache and restarting Visual Studio helps?

[sh0ckj0ckey]

Thank you so much for your suggestion! Clearing the NuGet cache and restarting Visual Studio actually solved the problem. I can't believe I forgot to try that earlier. Really appreciate your help!

[Medality]

Hi all!

First, let me thank all the passionate devs responsible for bringing modern .NET to UWP!

I've been able to successfully migrate my app to .NET 9. It was not an easy task, and I've hit a few bumps here and there, but in the end I think it was worth it :).

I've been able to generate MSIX files for x86/x64/ARM64, and use MakeAppx to create a bundle, but I'm not able to let Visual Studio create the bundle for me. When I try, I get the following error:
C:\Users\julie\.nuget\packages\microsoft.windows.sdk.buildtools.msix\1.3.20250314.1\build\Microsoft.Windows.SDK.BuildTools.MSIX.Packaging.targets(2325,5): error MSB4036: The "WinAppSdkSignAppxPackageBundle" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\arm64" directory.

I'm wondering if this issue is specific to ARM64 VS (I'm coding on a Snapdragon X Surface Pro), or if it's something I did wrong during the migration process.

Thanks!

[Sergio0694]

Are you on VS 17.14? Can you also try this (in your .csproj):

<MicrosoftWindowsSDKBuildToolsMSIXPackageVersion>1.7.20250508.1</MicrosoftWindowsSDKBuildToolsMSIXPackageVersion>

[Medality]

Thanks for the quick reply.
I just tried it and got the same error message (but from .nuget\packages\microsoft.windows.sdk.buildtools.msix\1.7.20250508.1).
I'm on the latest VS version, which is 17.14.3.
I also tried on a x64 PC, with the same result.
Thanks for your help!

[jp-weber]

I am currently in the process of modernising my UWP project.

Are there any known issues with Microsoft.Services.Store.Engagement? If I have installed CsWinRT + Microsoft.Services.Store.Engagement and added the SDK reference for Microsoft.Services.Store.Engagement, the namespace is not accessible

  <ItemGroup>
    <PackageReference Include="Microsoft.Services.Store.Engagement" Version="10.2307.3001" />
    <PackageReference Include="Microsoft.Windows.CsWinRT" Version="2.2.0" />
  </ItemGroup>
  <ItemGroup>
    <SDKReference Include="Microsoft.Services.Store.Engagement, Version=10.0" />
  </ItemGroup>

If I remove CsWinRT, the namespace of reference Microsoft.Services.Store.Engagement is accessible but the error appears.

[dongle-the-gadget]

You should reference CsWinRT and add this to your csproj:

<CsWinRTIncludes>Microsoft.Services.Store.Engagement</CsWinRTIncludes>

[jp-weber]

Thank you that works perfectly