XamlCodeGenerator fails when using MarkupExtension with parent having x:Load and x:Name

[d2dyno1]

Current behavior

I'm using a custom MarkupExtension to localize strings from resources. It has a property Name which is used to retrieve resource IDs to translate. As of Uno 5.4.x I'm unable to build my app on maccatalyst, linux, and Windows due to failing XamlCodeGenerator.

UnoApp54.zip

The issue appears to be hiding in Uno's XamlFileGenerator. I found references to the value I specified in the source-generated file which in turn does not have a declaring field.

("XamlSourceGenFails" is a string that I used in the aforementioned markup extension's Name property)

Expected behavior

The property value of the markup extension should neither be generated nor used by the source generator (see behavior on Uno 5.3.x)

How to reproduce it (as minimally and precisely as possible)

1. Create a new Uno 5.4.x app from templates (ideally a very basic one)
2. Implement a custom markup extension and add a sample string property (e.g. public string? Name { get; set; } as well as override the ProvideValue() method
3. Add a simple TextBlock with Text using the markup extension and notice the issue does not appear
4. Add a parent StackPanel with x:Name and x:Load={x:Bind BoolPropertyThatIsTrueInCodeBehind, Mode=OneWay}
5. The parent stack panel should have a child TextBlock with markup extension used
6. Notice the build error

MainPage_1e31cc856b453925f395d79f21a90e1f.cs(159,13): Error CS0103 : The name '_XamlSourceGenFailsSubject' does not exist in the current context

This was tested on maccatalyst and Linux X11

Workaround

No workaround has been found. The best option is to stick with Uno 5.3.x

Works on UWP/WinUI

Yes

Environment

Uno.UI / Uno.UI.WebAssembly / Uno.UI.Skia, Uno.SourceGenerationTasks, Other

NuGet package version(s)

No response

Affected platforms

Mac Catalyst, Skia (Linux X11)

IDE

Visual Studio 2022, Rider macOS

IDE version

No response

Relevant plugins

No response

Anything else we need to know?

This bug is preventing me from migrating my app to the latest Uno version

[Youssef1313]

A possible temporary workaround is to rename ResourceString.Name to something else. It seems it's incorrectly treated as if it's an x:Name

This will be happening here

uno/src/SourceGenerators/Uno.UI.SourceGenerators/XamlGenerator/XamlFileGenerator.cs

Line 6222 in e160f6b

var nameMember = FindMember(element, "Name");

We need to check for x:Name (maybe FrameworkElement.Name if we do generate a backing field for, I can't recall)