[XSG] Add heuristic to support bindable properties generated by other source generators

[Copilot]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Description of Change

The XAML source generator fails with error MAUIX2002 when trying to bind to properties that have their BindableProperty field generated by another source generator (e.g., CommunityToolkit.Maui's [BindableProperty] attribute), because source generators run independently and cannot see each other's output.

This PR implements a heuristic to detect and support such properties, allowing bindings to work correctly.

Implementation Details:

The heuristic detects properties/fields with recognized bindable property attributes and generates appropriate code:

• For BindingBase values: generates SetBinding call
• For literal values: generates SetValue call (not property setter)
• Supports optional PropertyName parameter on attributes for explicit property name specification
• Integrated into CanSetBinding and CanSetValue methods, keeping SetPropertyValue structure unchanged

Recognized Attributes:

The heuristic recognizes these specific attribute types by their full names:

• CommunityToolkit.Maui.BindablePropertyAttribute
• SQuan.Helpers.Maui.Mvvm.BindablePropertyAttribute
• Maui.BindableProperty.Generator.Core.AutoBindableAttribute

The list of recognized attributes is easily extensible by adding to the RecognizedBindablePropertyAttributes array. Only exact full name matches are supported to ensure specificity and prevent false positives.

Name Matching Strategy:

The heuristic checks these name patterns:

• Exact match (properties): Balance → property Balance
• Underscore prefix (fields): Balance → field _balance
• Lowercase first letter (fields): Balance → field balance
• Uppercase first letter (fields): Balance → field Balance

Files Changed (3 files):

1. src/Controls/src/SourceGen/ITypeSymbolExtensions.Maui.cs - Heuristic detection logic with helper methods and recognized attribute list
2. src/Controls/src/SourceGen/SetPropertyHelpers.cs - Integration into CanSetBinding and CanSetValue methods
3. src/Controls/tests/SourceGen.UnitTests/InitializeComponent/BindablePropertyHeuristic.cs - Comprehensive test coverage with real-world attribute namespaces (14 new tests)

Code Structure:

The heuristic is cleanly integrated into the existing code structure:

• CanSetBinding checks the heuristic when BP is null and value is BindingBase
• CanSetValue checks the heuristic when BP is null and value is not BindingBase
• SetBinding and SetValue handle both normal BP case and heuristic case with minimal duplication
• SetPropertyValue structure unchanged - continues calling Can* methods in order

This ensures:

• Real BindableProperties are always used first
• Source-generated BPs (detected via heuristic) use SetBinding/SetValue
• Only properties without BPs use property setters
• Clean separation of concerns

Test Results:

• ✅ All 14 BindablePropertyHeuristic tests pass
• ✅ All 100 SourceGen.UnitTests pass
• ✅ All 1746 Xaml.UnitTests pass

Example:

// User code with source-generated BindableProperty
public class BalanceView : Label
{
    [CommunityToolkit.Maui.BindableProperty]  // Generates BalanceProperty field at runtime
    public double Balance { get; set; }
}

<!-- XAML that previously failed with MAUIX2002, now works -->
<local:BalanceView Balance="{Binding Value}" />

Generated code:

// For binding:
balanceView.SetBinding(BalanceView.BalanceProperty, binding);

// For literal value:
balanceView.SetValue(BalanceView.BalanceProperty, 42.0);

Issues Fixed

Fixes #32596

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[XSG] Use heuristic to identify bindable properties generated by another source generator</issue_title>
<issue_description>There are libraries which generate the BindableProperty boilerplate based on a partial property or on a field annoated by some attribute. It can look something like this:

[BindableProperty]
public partial string Title { get; set; }

or

[BindableProperty]
private string _title;

The source generator creates the long declaration of the bindable property field:

public static BindableProperty <name>Property = BindableProperty.Create(...);

Since Roslyn source generators run independently of each other, our XAML SourceGenerator cannot see these generated bindable property static fields. This breaks apps which rely on this mechansim. For example:

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage
    x:Class="BalancePage"
    xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
    xmlns:local="clr-namespace:App"
    x:DataType="local:BalancePage">

    <VerticalStackLayout>
        <Slider x:Name="BalanceSlider" />
        <local:BalanceView Balance="{Binding Source={x:Reference BalanceSlider}, x:DataType='Slider', Path=Value}" />
    </VerticalStackLayout>
</ContentPage>

namespace App;

public partial class BalanceView : Label
{
	[BindableProperty] public partial double Balance { get; set; } = 0.0;

	public BalanceView()
	{
            // ...
	}
}

This currently fails with the following error:

error MAUIX2002: No accessible property, BindableProperty, or event found for "Balance", or mismatching type between value and property.

I imagine we implement a heuristic which will detect that we are trying to assign a BindingExtension node to a property or a field which has "similar" name to the XAML property name ("Balance", "_balance", "balance") and the property or field has an attribute which is called "BindablePropertyAttribute".

I would start by creating a PoC with SourceGen.UnitTests coverage. Let's see if this is feasible or not before we commit to this feature.

Later, we might allow more different attribute names to meet the expectations of the community and we might allow more distance between the XAML property name and the property/field name.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [Proposal][XSG] Use heuristic to identify bindable properties generated by another source generator #32596

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[rmarinho]

@copilot Seems alot of code changes here not related with fixes, can you just commit the changes for the issue in question.

[Copilot]

@copilot Seems alot of code changes here not related with fixes, can you just commit the changes for the issue in question.

Removed the formatting commit (bc7ccd0). The PR now contains only the 3 files directly related to the fix:

• ITypeSymbolExtensions.Maui.cs (heuristic detection)
• SetPropertyHelpers.cs (integration)
• BindablePropertyHeuristic.cs (tests)

Commit 52d2097

[simonrozsival]

@copilot you only added tests for AutoPropertyAttribute. I would also like to see tests for BindablePropertyAttribute. Change those tests into [Theory], ideally just one, and add parameters to test all the relevant inputs and their expected outputs.

[Copilot]

@copilot you only added tests for AutoPropertyAttribute. I would also like to see tests for BindablePropertyAttribute. Change those tests into [Theory], ideally just one, and add parameters to t...

Consolidated tests into a Theory with 6 InlineData test cases covering all combinations of BindablePropertyAttribute/AutoPropertyAttribute with properties/fields and with/without PropertyName parameter. Added 3 additional Fact tests for edge cases (missing attribute, mismatched names, literal values). All tests verify the correct SetBinding code is generated. Commit 7d9969c

[simonrozsival]

@copilot please make one more iteration

[simonrozsival]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[StephaneDelcroix]

/azp run MAUI-UITests-public

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).