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.

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

Sure, how can I collect them?

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

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

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

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.

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.

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

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.

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

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

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.

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.

I also am stuck on UWP mostly for XBox support.

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 🙂

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

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

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.

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.

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

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.

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?

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!

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 😊

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 🙂

This matches what @dongle-the-gadget said

Can you please point me to this?

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.

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

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

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!

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

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 🥲

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

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.

ok, so I'll wait a bit

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

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.

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

FYI you can remove:

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

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

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.

@Sergio0694 could this be a GC hole?

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.

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