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 withdotnet because I have a fewvcxproj, butmsbuild ... /bl seems to do the trick. Only thing is that it seems to start from scratch every time...

@FrayxRulez can youfollow 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 someplanned 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 inhttps://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 addingPRIResource-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.

InvalidCastException when marshalling enumerables of WinRT types to WinRT

I filedCsWinRT #1839. After recognizing that modern UWP defaults toDynamicCodeSupport=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!

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

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

    <frameworkReferences>      <grouptargetFramework="net6.0" />      <grouptargetFramework="net6.0-windows7.0">        <frameworkReferencename="Microsoft.WindowsDesktop.App.WPF" />      </group>      <grouptargetFramework=".NETFramework4.7.2" />      <grouptargetFramework=".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.

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.

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 fornet8.0-windows.

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

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 finalresources.pri file for the UWP project that is not picked up by the packaging project.

What is needed is aproject.pri to include all .resw and content files in the finalresources.pri in the package.
The simple solution:

• settingEnableMsixTooling tofalse 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 furtherPRIResource or file duplications.ms-appx URIs work as expected.
@Sergio0694 Sadly, I can not prepare a PR forMicrosoft.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 usingGC.KeepAlive, or copy the data to another memory address that you can control.

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

There are no plans to change that. Building UWP apps requires MSBuild Desktop, that's just by design. That said, youshould 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 usemsbuild from there (instead ofdotnet 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 😅

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 postYou’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 toMicrosoft.Windows.SDK.CPP version10.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 toMicrosoft.Windows.SDK.CPP version10.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.

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

"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 describedhere 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 APIsas 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.

That helps - thank you!

"should I expect to have problems calling some WinRT APIsas 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

Ah, some static "GetForCurrentView" calls (such as SpatialInteractionManager.GetForCurrentView) were returning 0x80070490 (Element Not Found). Looking around the web, that lead me tothis 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?

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 🙂

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.

Thank you Sergio!

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

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 🙂

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

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

You need to setGenerateAppxPackageOnBuild 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 usingwin10- runtime identifiers, and usewin- instead.

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?

Yes, that's why I said to only enable itin 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.

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

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.