Issues with reflection where the return type of GetMember is an empty array of MemberInfo

[adityapatwardhan]

Description

When trying to get the IsInterface member System.Runtimetype we get back an empty array of MemberInfo.
Expected to have 1 item in the array

Reproduction Steps

Project file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
</Project>

Program.cs:

using System.IO;

var t = typeof(Path).Assembly.GetType("System.IO.Path");
Console.WriteLine($"Value == {t?.IsInterface}");

Console.WriteLine($"{t?.GetType()}");
var member =  t?.GetType().GetMember("IsInterface");

if (member is not null)
{
    Console.WriteLine($"{member.GetType()}");
    Console.WriteLine($"{member.Length}");
}

Expected behavior

Value == False
System.RuntimeType
System.Reflection.MemberInfo[]
1

Actual behavior

Value == False
System.RuntimeType
System.Reflection.MemberInfo[]
0

Regression?

This is a regression from .NET 8

Known Workarounds

None

Configuration

.NET 9 Preview 1
Failures happen on Windows, Linux and Mac

Other information

No response

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

Issue Details

---

Description

When trying to get the IsInterface member System.Runtimetype we get back an empty array of MemberInfo.
Expected to have 1 item in the array

Reproduction Steps

Project file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
</Project>

Program.cs:

using System.IO;

var t = typeof(Path).Assembly.GetType("System.IO.Path");
Console.WriteLine($"Value == {t?.IsInterface}");

Console.WriteLine($"{t?.GetType()}");
var member =  t?.GetType().GetMember("IsInterface");

if (member is not null)
{
    Console.WriteLine($"{member.GetType()}");
    Console.WriteLine($"{member.Length}");
}

Expected behavior

Value == False
System.RuntimeType
System.Reflection.MemberInfo[]
1

Actual behavior

Value == False
System.RuntimeType
System.Reflection.MemberInfo[]
0

Regression?

This is a regression from .NET 8

Known Workarounds

None

Configuration

.NET 9 Preview 1
Failures happen on Windows, Linux and Mac

Other information

No response

Author:	adityapatwardhan
Assignees:	-
Labels:	area-System.Reflection, untriaged
Milestone:	-

[Joe4evr]

This is because IsInstance is declared on System.Type, not System.RuntimeType and by default GetMember()/GetMembers() does not take inherited members into account (BindingFlags.DeclaredOnly). If you pass a custom BindingFlags you can make it add inherited members to the search.

[adityapatwardhan]

The behavior has changed since .NET 8 though. PowerShell uses reflection extensively, so if the change is intentional, we need to know.

[MichalStrehovsky]

This was broken in #92512 that introduced an internal property named IsInterface on RuntimeType. What PowerShell is doing is private reflection on implementation details of the BCL. What is happening is this:

Console.WriteLine(typeof(C1).GetMember("P").Length); // Prints 1
Console.WriteLine(typeof(C2).GetMember("P").Length); // Prints 0

class C1
{
    public bool P { get; set; }
}

class C2 : C1
{
    internal new bool P { get; set; }
}

We don't issue breaking change notices when we change private implementation details of the BCL.

The PowerShell code needs to be updated to use typeof(Type).GetMember("IsInterface") to reflect on public surface area, not on members of the undocumented RuntimeType.

[jkotas]

What PowerShell is doing is private reflection on implementation details of the BCL.

It is an interesting question whether this constitutes a private reflection. Do we consider queries for public (inherited) methods on internal type to be a private reflection? It is very common for code out there to do that.

BindingFlags.Public are the default, so one would expect that the API is only going to consult public members. Unfortunately, it is not the case. The internal member hides the inherited public member.

[steveharter]

by default GetMember()/GetMembers() does not take inherited members into account (BindingFlags.DeclaredOnly).

The default for this case does not include DeclaredOnly. The default is BindingFlags.Instance | BindingFlags.Static | BindingFlags.Public.

The PowerShell code needs to be updated to use typeof(Type).GetMember("IsInterface") to reflect on public surface area, not on members of the undocumented RuntimeType.

Yes using typeof(Type) is the most "correct" way IMO to query for members for any case when you know the type + member you want to reflect on; calling GetType() only adds unnecessary questions.

It is an interesting question whether this constitutes a private reflection. Do we consider queries for public (inherited) methods on internal type to be a private reflection? It is very common for code out there to do that.

Since calling obj.GetType() on a non-sealed but public class may return a non-public type, some thought is needed when using reflection + obj.GetType() as to why. As I mentioned earlier, if you know the type + member you want to reflect on, just use typeof(Foo) otherwise you may get an unexpected class and the non-intuitive behavior with the new\newslot modifier.

BindingFlags.Public are the default, so one would expect that the API is only going to consult public members. Unfortunately, it is not the case. The internal member hides the inherited public member.

That is unfortunate and seems like a reflection issue that can no longer be addressed. We could change the modifier on RuntimeType to be public instead of internal which would address this, although I'm inclined to just close this issue as by design.

[jkotas]

That is unfortunate and seems like a reflection issue that can no longer be addressed.

Why not? new is rarely used feature. I think it would be acceptable to fix the reflection behavior for it if we decided that it is the right thing to do.

This issue is not present in native AOT implementation of reflection. I have not checked Mono and MetadataLoadContext. We should add a test case for this and either introduce the issue in all reflection implementations or fix the issue in all reflection implementations.

[steveharter]

Why not? new is rarely used feature. I think it would be acceptable to fix the reflection behavior for it if we decided that it is the right thing to do.

It would be a breaking change that's all. If we're OK with that, I can move this issue to v9 with that task.