GetProperties and GetProperty returning different answers in .NET 9 even with BindingFlags.FlattenHierarchy

[samcook-mathworks]

Description

System.RuntimeType no longer seems to define the IsInterface property when inspecting via reflection. I'm not sure if this is a change in System.RuntimeType, but using the BindingFlags.FlattenHierarchy ought to return it for all subclasses of Type.

So, I propose the underlying issue is that GetProperties GetProperty or BindingFlags.FlattenHierarchy no longer work as expected in .NET 9.

MATLAB relies on the existing behavior, so this is another way that .NET 9 has broken integration with MATLAB.

Reproduction Steps

using System;
using System.Linq;
using System.Reflection;

Console.WriteLine(Environment.Version);
var runtimeType = System.Type.GetType("System.RuntimeType");
Console.WriteLine(runtimeType);

// This used to work
var props = runtimeType.GetProperties();
var isInterfaceProp = props.FirstOrDefault(p => p.Name == "IsInterface");
Console.WriteLine(isInterfaceProp);

// This used to work
isInterfaceProp = runtimeType.GetProperty("IsInterface");
Console.WriteLine(isInterfaceProp);

// This used to work
isInterfaceProp = runtimeType.GetProperty("IsInterface", BindingFlags.Public | BindingFlags.FlattenHierarchy | BindingFlags.Instance);
Console.WriteLine(isInterfaceProp);

Observe in .NET 8 and lower, this returns the "IsInterface" property. In .NET 9, IsInterface is not found. I have only tested this on Windows.

Expected behavior

IsInterface is a public instance property of all subclasses of System.Type, especially when using BindingFlags.FlattenHierarchy.

Actual behavior

IsInterface is only returned when inspecting non-public properties. Which doesn't make sense, because IsInterface is a public property of System.Type.

Regression?

Yes. This worked as expected in .NET 8 and lower, including .NET Framework.

Known Workarounds

No response

Configuration

Environment.Version == 9.0.8
dotnet --version == 9.0.304

Other information

No response

[dotnet-policy-service]

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

[AaronRobinsonMSFT]

@samcook-mathworks I'll take a look at this today.

[jkotas]

Related / duplicate of #98533

[samcook-mathworks]

After reviewing more, it seems that in the case:

1. Superclass defines a public member.
2. Subclass defines a private member with the same name.
3. I'm using reflection to inspect Subclass.

that no combination of BindingFlags will be able return the superclass public member. If I want to really know all of a type's members, I must manually iterate through it and each superclass and interface to compile that list of public members.

On top of that, I have to make sure there are no duplicates in the list of members if a subclass has hidden a superclass member with public access. At this point, it feels like I'm writing my own implementation of BindingFlags.FlattenHierarchy which is no doubt less performant than yours.

Is that understanding correct?

I would argue this is incorrect behavior. The compiler can access the superclass member just fine - but reflection can't? From the MATLAB perspective, I'm just asking a type "what are the members a C# programmer could access when using your type?" and (until now) I assumed GetMembers/Properties/Methods APIs would answer that question. But perhaps that was never the intention?

For context, MATLAB must know an object's exact type. Consider an API that returns object - if you call it from MATLAB, users still have to know the runtime type of the object that was returned, and be able to interact with it. In other words, objects only ever exist as their implementation. I guess this behavior never popped up until now with the IsInterface issue reported by others, since that's a more visible API.

[AaronRobinsonMSFT]

Related / duplicate of #98533

@jkotas We can easily fix this issue. The problem is simply that RuntimeType has a non-public API that is marked with new that has the same name as a public API. Changing or removing the backwards compat filtering logic is the problem. Once this is removed, the expected filtering for public APIs will kick in. I don't have enough context about the duplicate nature the below filtering is attempting to fix.

runtime/src/coreclr/System.Private.CoreLib/src/System/RuntimeType.CoreCLR.cs

Lines 1319 to 1364 in bb71812

	#region Duplicate check based on name and signature
	// For backward compatibility, even if the vtable slots don't match, we will still treat
	// a property as duplicate if the names and signatures match.
	if (csPropertyInfos != null)
	{
	string name = propertyInfo.Name;
	if (!csPropertyInfos.TryGetValue(name, out List<RuntimePropertyInfo>? cache))
	{
	cache = new List<RuntimePropertyInfo>(1);
	csPropertyInfos[name] = cache;
	}
	for (int j = 0; j < cache.Count; j++)
	{
	if (propertyInfo.EqualsSig(cache[j]))
	{
	cache = null;
	break;
	}
	}
	if (cache == null)
	continue;
	cache.Add(propertyInfo);
	}
	else
	{
	bool duplicate = false;
	for (int j = 0; j < list.Count; j++)
	{
	if (propertyInfo.EqualsSig(list[j]!))
	{
	duplicate = true;
	break;
	}
	}
	if (duplicate)
	continue;
	}
	#endregion
	}

A narrow fix would be to also check if the method is non-virtual, which we could then assume it was defined with new in C#. That is a bespoke fix that doesn't really address the general issue. Another option would be to simply rename RuntimeType.IsInterface and it would then fix the two reported issues. These are all short-term fixes though. The real fix is to not perform this filtering so aggressively when doing the name/sig match.

[mikernet]

@samcook-mathworks The behavior also isn't consistent between properties and methods - see #28056.

[jkotas]

Questions and notes from offline discussion:

Are there other situations where this backward compatibility quirk kicks in, except for private new property hiding public property? Do we have any tests that fail when this backward compatibility quirk is deleted?

The effect of this compatibility quirk is that it is impossible to use public reflection reliability (without being potentially exposed to changes in private implementation details). It sounds like something we do want to fix.