Fixed AmbiguousMatchException in DataAnnotationsValidator for Hidden Members

[PreethikaSelvam]

Bug Description

This PR fixes an issue where the Blazor DataAnnotationsValidator throws an AmbiguousMatchException when validating models that contain hidden properties (i.e., derived class properties declared using new to hide base class members).

Fixes #27095

Problem

When a model includes properties with the same name in both base and derived classes, validation fails with: System.Reflection.AmbiguousMatchException. This breaks form validation scenarios in Blazor when inheritance with member hiding is used.

Root Cause

The issue originates from the use of: Type.GetProperty(string name). This reflection call returns multiple matches when both base and derived types define a property with the same name, resulting in ambiguity and an exception.

Solution Description

Added handling for AmbiguousMatchException. On exception, retried property resolution using:
BindingFlags.DeclaredOnly. This ensures that only properties declared on the current (derived) type are considered, avoiding ambiguity

Output Screenshots

Before Fix

GH27095BeforeFix.1.mp4

After Fix

GH27095AfterFix.mp4

Testing

Added 3 new unit test cases covering:

• Validation of models with hidden properties
• Ensuring no exception occurs and correct property resolution
• Manual testing performed to validate real-world scenarios

Impact

• Fixes runtime validation failure for inherited models with hidden members
• Improves robustness of DataAnnotationsValidator
• Ensures consistent behavior across reflection-based validation scenarios

PR Checklist

• Small and focused — Fixes a specific validation issue
• Tests added — 3 new unit tests included
• Code style matches — Follows existing patterns
• Local build passes
• Local tests pass (14/14)
• No breaking changes
• Issue linked (if applicable) — #27095
• Public API updates — Not applicable
• XML documentation

[dotnet-policy-service]

Thanks for your PR, @PreethikaSelvam. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[ilonatommy]

The CI is always running on PR branch merged to main. In case there would be unresolved conflicts, there would be an information about it on the PR. Merging with main when there are no conflicts and when you're not aware of any recent changes that could influence your feature prolongs the time-to-merge of the PR.

[ilonatommy]

/ba-g failures not connected

[Youssef1313]

FlattenHierarchy is only relevant for statics IIRC.

And this code can still throw if the previous call returned null and we get into here with some shadowing member in a base type.