How to migrate UWP .Net Native to UWP AOT

Question

How to migrate UWP .Net Native to UWP AOT

Hong 1,546

I read the official document on "Modernize your UWP app with .NET and Native AOT". The instructions for migrating .Net Native UWP to the new modern UWP are sketchy. It seems that one can just edit the existing .csproj to do the migration.

Specifically, change the root element to

Then add the following PropertyGroup:

  <PropertyGroup>     <OutputType>WinExe</OutputType>     <TargetFramework>net10.0-windows10.0.26100.0</TargetFramework> <!-- Use the latest supported .NET version -->     <TargetPlatformMinVersion>10.0.19041.0</TargetPlatformMinVersion>     <UseUwp>true</UseUwp>     <EnableMsixTooling>true</EnableMsixTooling>     <PublishAot>true</PublishAot>     <DisableRuntimeMarshalling>true</DisableRuntimeMarshalling>

Could anyone point me to a source with detailed instructions?

0 comments

3 answers

Your answer

Answer 1

Bruce (SqlWork.com) 85,276

While updating the project file is key first step, you need to update your nuget packages to native aot compatible versions also. If the nuget package is not under current development, it may need to be replaced. Third you may need to edit code that fails to compile to AOT.

0 comments

Answer 2

Vignesh vicky 0

Yes, the migration mainly involves updating the .csproj file to the modern UWP SDK-style project format and adding the required properties. However, check Microsoft’s “Modernize your UWP app with .NET and Native AOT” documentation for the complete requirements and limitations.

Hong 1,546 Reputation points

2026-09-09T11:24:31.16+00:00

Is the “Modernize your UWP app with .NET and Native AOT” documentation that you mentioned different from the one that I mentioned in my question? The one that I looked at does not provide sufficient clarification.

Answer 3

Gatlin Le (WICLOUD CORPORATION) 0 Microsoft External Staff Moderator

Hi @Hong ,

Thank you for taking the time to review the migration documentation and for raising this question.

Based on the information currently available, migrating a UWP application from .NET Native to UWP with Native AOT is a supported scenario. However, updating the project file alone is typically only the first step of the migration process.

While many applications may migrate successfully after the required project configuration changes, the overall experience can vary depending on the application's dependencies and implementation details. For example, it is important to verify that all NuGet packages used by the application are compatible with Native AOT, and some code changes may be required if the application relies on APIs or patterns that are not fully compatible with AOT compilation.

As Bruce mentioned, package compatibility and potential code updates should also be evaluated as part of the migration effort.

At this stage, without reviewing a specific project or encountering particular build/publish errors, it is difficult to predict whether any issues will arise during the migration. If you proceed with the migration and run into build, publish, or runtime errors, please feel free to share the details and we will be happy to investigate further.

I hope this helps clarify the migration expectations and potential considerations. If you found my response helpful or informative, I would greatly appreciate it if you could share your thoughts by reacting to this answer or leaving a comment.

Thank you.

Hong 1,546 Reputation points

2026-09-09T11:36:02.9966667+00:00

Thank you for lending a hand here.

As mentioned in my question, I know how to change the root tag and add newly required elements. I am not clear whether I need to change or delete any existing elements.

The following a typical existing .csproj file. It has many PropertyGroup and ItemGroup elements (I have all of them collapsed except for one). Should they be left intact when editing it? I know some will change when the NuGet Package Manager is used to modify packages.
Gatlin Le (WICLOUD CORPORATION) 0 Reputation points Microsoft External Staff Moderator

2026-09-10T04:12:12.6833333+00:00
Hi @Hong ,

Thank you for the clarification and for sharing the project file — that helps a lot.

From what is visible in your screenshot, here is how I would approach it:

Most of what you're seeing can go

Both Import statements — Microsoft.Common.props at the top of the file and Microsoft.Windows.UI.Xaml.CSharp.targets near the bottom. The SDK brings these in itself, and leaving them will cause conflicts.

All the per-configuration blocks (Debug and Release across x86, x64, ARM): OutputPath, DebugType, DebugSymbols, ErrorReport, Prefer32Bit, UseVSHostingProcess. The SDK has sensible defaults for each of these. One caveat — these blocks also hold your DefineConstants, so note those down before deleting. If your code has #if conditions relying on them, you'll want to confirm they still resolve on the new target framework.

Any ItemGroup that simply lists your .cs files, XAML pages or image assets by name — those are picked up automatically now.

What's specific to your app is worth carrying over

PackageReference entries, updated to Native AOT–compatible versions. If you're still on packages.config, bring across only the direct references; transitive ones resolve on their own.

ProjectReference entries.

Files with a non-default build action, or anything using CopyToOutputDirectory.

Your app identity and AppxManifest-related configuration.

One suggestion worth considering: Visual Studio 2026 includes templates for modern UWP apps, and starting fresh then copying your source and assets over is often less painful than editing the old file down — if the build breaks, you know it's your code rather than a leftover setting. Editing in place keeps your git history, so either approach is fine.

Either way, please back up first and rebuild after each chunk of changes rather than all at once.

Happy to go through it line by line if you paste the full .csproj as text with anything sensitive removed.
Hong 1,546 Reputation points

2026-09-10T10:07:34.54+00:00

Thank you for the detailed clarification, @Gatlin Le (WICLOUD CORPORATION) This helps a lot. They type of information should be in the official document.

Could you turn the above comment into an answer for me to accept?