Prefer most derived member in Configuration Binder source generator

[ericstj]

Fix #101267 #101273

CC @eerhardt

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

[tarekgh]

LGTM!

[eerhardt]

LGTM. Thanks for the quick fix here!

Do you think this could be backported to 8.0.x?

[eiriktsarpalis]

Per #101316 (review) I suspect that this might be introducing a slight regression.

Given that this is a likely candidate for backporting, it might make sense to investigate further.

[ericstj]

I'll add a test case for an override that only overrides the Getter. We did have a test for the case where a new member only provides a get - in which case we're intentionally not binding.

[ericstj]

Seems we still have a failure of the Reflection binder:

System.InvalidOperationException : Failed to convert configuration value at 'E' to type 'Microsoft.Extensions.Configuration.Binder.Tests.ConfigurationBinderTests+TestSettingsEnum'.
---- System.FormatException : OptionB is not a valid value for TestSettingsEnum.
-------- System.ArgumentException : Requested value 'OptionB' was not found.

@eerhardt -- does that sound right? That seems to indicate that #101273 might be broken even without the source generator.

[ericstj]

Interesting: the reflection binder has a different heuristic.

runtime/src/libraries/Microsoft.Extensions.Configuration.Binder/src/ConfigurationBinder.cs

Lines 987 to 1004 in c1f9161

	while (baseType != typeof(object))
	{
	PropertyInfo[] properties = baseType.GetProperties(DeclaredOnlyLookup);
	foreach (PropertyInfo property in properties)
	{
	// if the property is virtual, only add the base-most definition so
	// overridden properties aren't duplicated in the list.
	MethodInfo? setMethod = property.GetSetMethod(true);
	if (setMethod is null || !setMethod.IsVirtual || setMethod == setMethod.GetBaseDefinition())
	{
	allProperties.Add(property);
	}
	}
	baseType = baseType.BaseType!;
	}

It never does any resolution by name, but builds a list in order from derived to base. So it will set both the hidden and non-hidden members through reflection, using the same configuration data. That's unusual behavior - but we could replicate it if we casted the LHS in the source generator to the base type.

[tarekgh]

@ericstj I think we need to keep the runtime behavior for consistency. Even if it looks unusual behavior but seems not many people complained about it.

[eerhardt]

@eerhardt -- does that sound right? That seems to indicate that #101273 might be broken even without the source generator.

See my comment on #101273 (comment). For the case I hit the issue, the base enum is a superset of the derived enum. The derived class is trying to limit which values can be set.

[eiriktsarpalis]

That's unusual behavior - but we could replicate it if we casted the LHS in the source generator to the base type.

Do we want to? Are there tests validating this behavior?

[ericstj]

I'm not planning to change the reflection binder's behavior in this PR. Nor am I planning to change the source generator to bind many different propreties like the reflection binder does.

I'm inclined to more closely match the reflection-binder's selection algorithm for finding the most-derived property. I think that will be the minimal change while unblocking @eerhardt. I'm running some tests and will make a new change to this PR shortly.

[ericstj]

Failures are known issues and don't block build or testing.

[ericstj]

/backport to release/8.0-staging

[github-actions]

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8881506956