Fix Navigation for Native AOT with Source Generator #1627

[ghost1372]

Add a source generator to automatically generate the NavigationPageMappings class, which maps page types to unique IDs. This eliminates the need to use reflection, such as Type.GetType(pageString). #1627

Before:

string pageString = $"{pageRoot}{item.UniqueId}Page";
Type? pageType = Type.GetType(pageString);

After:
NavigationPageMappings.PageDictionary.TryGetValue(item.UniqueId, out Type? pageType);

Description

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

[ghost1372]

Hi
@marcelwgn
@niels9001
can you review this pr?
tnx

[marcelwgn]

Thank you for working on this, great job!

General question, do we need to include the fully qualified type name? I think for simplicity we can get away with just having the type name itself as key instead of having to prepend "WinUIGallery..." everwhere.

[Zakariathr22]

I have a few questions:

• What value would Native AOT bring to the Gallery, and is it actually necessary? Please correct me if I am mistaken, but my understanding is that Native AOT becomes truly beneficial primarily for very large applications with extensive functionality, where startup time and performance are critical.

• Is Microsoft planning to make Native AOT adoption easier? At the moment, I see many pull requests relying on workarounds and complex, fragile code paths just to make it work, often without achieving a stable or satisfactory result.

• Is there any official guide or step-by-step documentation for implementing Native AOT in existing WinUI applications, or should we consider creating such documentation ourselves?

[ghost1372]

Hello everyone, I apologize for the delay in responding. If you follow the news from Iran, for about the past three weeks, due to protests and unrest, the internet was completely (100%) shut down, and we had no access to anything. As of today, some changes have occurred and a few services, such as GitHub, are accessible again. Things are still not back to normal, and there is always the possibility of reverting to the previous conditions at any moment.

Thank you @marcelwgn for review.
It’s not strictly necessary, but it does help us easily use pages regardless of which namespace they are in. In practice, this also helps protect us from future changes. The decision is up to you — should I use the simpler approach, or use the fully qualified namespace in the file?

@Zakariathr22
AOT is great not only for large applications, but also for small ones. In addition to the points you mentioned (performance and fast startup), it also helps reduce the binary size.
Using AOT is very straightforward. There are just a few simple, general rules that need to be followed. For the Gallery, its implementation was done across different PRs to keep the review process quick and simple.
Make the classes partial, avoid using reflection, use x:Bind, use CsWin32 (with disabled marshaling) or LibraryImport for P/Invoke, enable the AOT support flag, and address the warnings.

I don’t have access to the Microsoft sites right now because of the outage that’s going on, but the related documentation still exists and you can find it with a little searching.

[marcelwgn]

Adding to @ghost1372 answers:

What value would Native AOT bring to the Gallery, and is it actually necessary? Please correct me if I am mistaken, but my understanding is that Native AOT becomes truly beneficial primarily for very large applications with extensive functionality, where startup time and performance are critical.

As a project that is also oftenly used by people to look for guidance and how to implement things, showing what steps might be necessary to be AOT compatible, I think this project should be AOT compatible. While for bigger apps, the startup performance benefit is bigger, I expect we would still have a small perf benefit (especially for JSON parsing) as well as smaller size foot print. One thing that AOT also enables is assembly trimming so its a double win in that sense.

Is Microsoft planning to make Native AOT adoption easier? At the moment, I see many pull requests relying on workarounds and complex, fragile code paths just to make it work, often without achieving a stable or satisfactory result.

I think some of the workarounds you see in this PR are also just due to how the code in the gallery is structured. Whenever you do something that does reflection lookups, e.g. finding a type by name, that is something a compiler cannot meaningful know ahead of time. Think about this scenario: What if you modified your local controls.json file to contain a different type name? The compiler wont know what you might write in there so we need to handle these cases. In most apps, having this "lookup a page by a raw string" is not a problem so at least they wont need the work of this app. The same goes for things like the JSON parsing, pretty much as soon as you accept user input, e.g. via a file, you have to specify what things you will accept or not.

Is there any official guide or step-by-step documentation for implementing Native AOT in existing WinUI applications, or should we consider creating such documentation ourselves?

Since the AOT we are talking about here is a .Net feature, most of the documentation on this are coming from the .Net side of things. If you are using WinUI 3 with C++, you do not have to think about this matter at all since C++ is already NAOT per definition.

[niels9001]

/azp run

[Zakariathr22]

Adding to @ghost1372 answers:

What value would Native AOT bring to the Gallery, and is it actually necessary? Please correct me if I am mistaken, but my understanding is that Native AOT becomes truly beneficial primarily for very large applications with extensive functionality, where startup time and performance are critical.

As a project that is also oftenly used by people to look for guidance and how to implement things, showing what steps might be necessary to be AOT compatible, I think this project should be AOT compatible. While for bigger apps, the startup performance benefit is bigger, I expect we would still have a small perf benefit (especially for JSON parsing) as well as smaller size foot print. One thing that AOT also enables is assembly trimming so its a double win in that sense.

Is Microsoft planning to make Native AOT adoption easier? At the moment, I see many pull requests relying on workarounds and complex, fragile code paths just to make it work, often without achieving a stable or satisfactory result.

I think some of the workarounds you see in this PR are also just due to how the code in the gallery is structured. Whenever you do something that does reflection lookups, e.g. finding a type by name, that is something a compiler cannot meaningful know ahead of time. Think about this scenario: What if you modified your local controls.json file to contain a different type name? The compiler wont know what you might write in there so we need to handle these cases. In most apps, having this "lookup a page by a raw string" is not a problem so at least they wont need the work of this app. The same goes for things like the JSON parsing, pretty much as soon as you accept user input, e.g. via a file, you have to specify what things you will accept or not.

Is there any official guide or step-by-step documentation for implementing Native AOT in existing WinUI applications, or should we consider creating such documentation ourselves?

Since the AOT we are talking about here is a .Net feature, most of the documentation on this are coming from the .Net side of things. If you are using WinUI 3 with C++, you do not have to think about this matter at all since C++ is already NAOT per definition.

@marcelwgn, thanks for the clarification, at this point I think the app should use C++ at the first place 😄