Fix ambiguous hidden-property lookup in validation

[Copilot]

Fixes #64728

[Copilot]

Pull request overview

This PR fixes a reflection edge case in the validation pipeline where property lookup could throw AmbiguousMatchException when a derived type hides an inherited property with the same name. It aligns runtime property resolution with the declaring type information already emitted by the validation source generator.

Changes:

• Resolve properties in ValidatablePropertyInfo using BindingFlags.Instance | BindingFlags.Public | BindingFlags.DeclaredOnly to avoid ambiguous matches from inherited members.
• Add a regression test covering a hidden-property scenario and running both sync and async validation paths.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/Validation/src/ValidatablePropertyInfo.cs	Switches reflection lookup to declared-only to prevent AmbiguousMatchException when properties are hidden in an inheritance chain.
src/Validation/test/Microsoft.Extensions.Validation.Tests/ValidatableTypeInfoTests.cs	Adds regression coverage for validating a derived type that hides a base property with the same name (sync + async paths).

[mguinness]

Will this change be backported to .NET 10?

[oroztocil]

We should have a test case that uses generics as in the original report (#64728). I remember from playing with the scenarios in the past that it changes the situation when the property has a generic type on level and non-generic on another. I understand that the BindingFlags.DeclaredOnly should implicitly avoid this as well but I would rather have it covered.

public class ODataQueryOptions
{
     public virtual ETag IfMatch
     {
          ...
     }
}

public ODataQueryOptions<T> : ODataQueryOptions
{
    public new ETag<T> IfMatch
    {
        get
        {
            return base.IfMatch as ETag<T>;
        }
}

[Youssef1313]

@copilot Address #67455 (review).

[Youssef1313]

Will this change be backported to .NET 10?

@mguinness It's not yet decided.

[Copilot]

@copilot Address #67455 (review).

Addressed in commit cf4a5df5. I added a regression test that covers the generic/non-generic hidden IfMatch property scenario (sync + async) to match the original issue shape.

[oroztocil]

There are also GetProperty calls emitted in https://github.com/dotnet/aspnetcore/blob/main/src/Validation/gen/Emitters/ValidationsGenerator.Emitter.cs#L157 and https://github.com/dotnet/aspnetcore/blob/main/src/Validation/gen/Emitters/ValidationsGenerator.Emitter.cs#L309

These should probably have the same flags.

[Youssef1313]

@copilot Add a failing test covering the two GetProperty calls in the generated code, and then change it to use the same BindingFlags as already done ValidatablePropertyInfo, and ensure that test passes afterwards.

[Copilot]

@copilot Add a failing test covering the two GetProperty calls in the generated code, and then change it to use the same BindingFlags as already done ValidatablePropertyInfo, and ensure that test ...

Done in 03e7cd35.

I added a generator regression test that reproduces the hidden generic/non-generic property ambiguity in generated code (PropertyDisplayName_WithResourceType_OnHiddenGenericProperty), then updated both emitted GetProperty call sites to use BindingFlags.Instance | BindingFlags.Public | BindingFlags.DeclaredOnly. The new test fails before the emitter change and passes after it.

[Youssef1313]

There are also GetProperty calls emitted in https://github.com/dotnet/aspnetcore/blob/main/src/Validation/gen/Emitters/ValidationsGenerator.Emitter.cs#L157 and https://github.com/dotnet/aspnetcore/blob/main/src/Validation/gen/Emitters/ValidationsGenerator.Emitter.cs#L309

These should probably have the same flags.

Thanks for pointing out to these! Addressed in the last commit via Copilot.

[oroztocil]

Looks good!