Skip to content

Fix UsesReflectionBasedBindingsWhenCompilationOfBindingsWithSourceIsDisabled Xaml.UnitTests fails in candidate branch - #36592

Merged
kubaflo merged 2 commits into
dotnet:inflight/candidatefrom
KarthikRajaKalaimani:fix-23711-2
Jul 15, 2026
Merged

Fix UsesReflectionBasedBindingsWhenCompilationOfBindingsWithSourceIsDisabled Xaml.UnitTests fails in candidate branch#36592
kubaflo merged 2 commits into
dotnet:inflight/candidatefrom
KarthikRajaKalaimani:fix-23711-2

Conversation

@KarthikRajaKalaimani

@KarthikRajaKalaimani KarthikRajaKalaimani commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

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!

Issue Details:

UsesReflectionBasedBindingsWhenCompilationOfBindingsWithSourceIsDisabled test case is failed

Root Cause:

PR #35798 introduced a guard in SetPropertiesVisitor.cs to stop XamlC from compiling a TypedBinding whenever Source is RelativeSource / x:Reference and x:DataType isn't declared directly on the binding node ( !xDataTypeIsOnBindingNode ). The problem: this condition is too broad. It was meant to catch one specific dangerous case — x:DataType inherited from an enclosing DataTemplate , which describes the template item type, not the actual RelativeSource / x:Reference target — but it also caught a harmless case: x:DataType inherited from a plain ancestor like ContentPage (no DataTemplate involved), where the inherited type is still perfectly valid to bind against directly.

Description of Change:

The guard condition changed from !xDataTypeIsOnBindingNode to xDataTypeIsInOuterScope — a flag already computed earlier in the method, set to true only when the tree-walk to find x:DataType passes through a DataTemplate node. This precisely targets the one case #35798 actually needed to guard against (DataTemplate-inherited types being wrongly applied to a RelativeSource/x:Reference target), while leaving alone the case where x:DataType is inherited from a normal ancestor (like ContentPage ) or declared directly on the binding node — both of which can safely use the resolved dataTypeNode type as-is.

Tested the behavior in the following platforms:

  • Android
  • Windows
  • iOS
  • Mac

Reference:

N/A

Issues Fixed:

Fixes #36563

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 1 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

@dotnet-policy-service dotnet-policy-service Bot added the community ✨ Community Contribution label Jul 15, 2026
@dotnet-policy-service

Copy link
Copy Markdown
Contributor

Hey there @@KarthikRajaKalaimani! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

@dotnet-policy-service dotnet-policy-service Bot added the partner/syncfusion Issues / PR's with Syncfusion collaboration label Jul 15, 2026
@sheiksyedm
sheiksyedm marked this pull request as ready for review July 15, 2026 14:19
@sheiksyedm
sheiksyedm requested a review from kubaflo July 15, 2026 14:19
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 1 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

@kubaflo
kubaflo merged commit 22d4c97 into dotnet:inflight/candidate Jul 15, 2026
11 of 19 checks passed
@github-actions github-actions Bot added this to the .NET 10 SR10 milestone Jul 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

community ✨ Community Contribution partner/syncfusion Issues / PR's with Syncfusion collaboration

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants