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.

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

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

[andrew-kulikov]

I faced an issue trying to run my application published with NativeAOT. When testing unpackaged version everything works fine, but published application always crashes in random places of custom application startup logic with error The thread tried to read from or write to a virtual address for which it does not have the appropriate access. Also I found that regardless of the location in app code, all crash stack traces end like this:

MyApp.exe!WKS::gc_heap::mark_phase(int condemned_gen_number) Line 30225	C++
MyApp.exe!WKS::gc_heap::gc1() Line 22402	C++
MyApp.exe!WKS::gc_heap::garbage_collect(int n) Line 24513	C++
MyApp.exe!WKS::GCHeap::GarbageCollectGeneration(unsigned int gen, gc_reason reason) Line 51065	C++
MyApp.exe!WKS::gc_heap::trigger_gc_for_alloc(int gen_number, gc_reason gr, WKS::GCDebugSpinLock * msl, bool loh_p, WKS::msl_take_state take_state) Line 18927	C++
[Inline Frame] MyApp.exe!WKS::gc_heap::try_allocate_more_space(alloc_context *) Line 19047	C++
MyApp.exe!WKS::gc_heap::allocate_more_space(alloc_context * acontext, unsigned int size, unsigned int flags, int alloc_generation_number) Line 19547	C++
[Inline Frame] MyApp.exe!WKS::gc_heap::allocate(unsigned int) Line 19578	C++
MyApp.exe!WKS::GCHeap::Alloc(gc_alloc_context * context, unsigned int size, unsigned int flags) Line 49969	C++
MyApp.exe!GcAllocInternal(MethodTable * pEEType, unsigned int uFlags, unsigned int numElements, Thread * pThread) Line 542	C++
MyApp.exe!RhpGcAlloc(MethodTable * pEEType, unsigned int uFlags, unsigned int numElements, PInvokeTransitionFrame * pTransitionFrame) Line 603	C++
MyApp.exe!@RhpNewFast@4() Line 67	Unknown
...
randon applicaiton method allocating new object

The app uses DirectX via SharpDX bindings to render it's content into SwapChainPanel. On startup we load some textures, build object graphs and register services in Autofac container.

Do you have any ideas what can cause such crashes (bug in runtime, access to trimmed types, native interop, unsafe code, etc.)?

[dongle-the-gadget]

@Sergio0694 could this be a GC hole?

[andrew-kulikov]

Important notice - it appears to be only win-x86 problem. I tried to compile using win-x64, and there are no such errors. App still crashes, but the problem is with trimmed constructors and not related to this case.

[andrew-kulikov]

Created an issue in runtime related to this problem dotnet/runtime#110607