Why do CanRead and CanWrite return false in C# for properties with overridden accessors?

Question

When trying to get properties accessors from derived properties or use CanRead / CanWrite, for some reason base auto-properties are not taken into account.

Can

Answer 1

As Peter Duniho explains in his answer, this seems to require some work.

It would be easier if PropertyInfo had something like GetBaseDefinition(), but it does not (also this thread), so we have to go through the accessor method. It would also be easier if the method info for the accessor had a reference back to the property info, but it does not, so we run through all properties and assume there is exactly on match.

So here is a naive solution:

// does not necessarily work as expected if the property or one of its accessors
// (getter or setter) is not public
internal static bool CanReadExt(PropertyInfo pi)
{
  if (pi.CanRead)
    return true;

  // assume we have a setter since we do not have a getter
  var setter = pi.SetMethod
    ?? throw new Exception("Neither getter nor setter in property?");

  // try to acquire setter of base property
  var baseSetter = setter.GetBaseDefinition();

  // if the property was not overridden, we can return
  if (setter.DeclaringType == baseSetter.DeclaringType)
    return false;

  // try to find the base property
  var basePi = baseSetter.DeclaringType.GetProperties()
    .SingleOrDefault(x => x.SetMethod == baseSetter)
    ?? throw new Exception("Set accessor was overridden but we could not find property info for base property.");

  // recursively call ourselves
  return CanReadExt(basePi);
}

It returns true with your PropertiesReflectionTests.Property, so it works in that case. More care would be needed to handle every case, I guess.

This method can be made an extension method if you prefer.

A similar method CanWriteExt could be written.

Answer 2

I expected last two tests to pass, what am I missing?

For a definitive answer, you'd have to ask the people who originally designed .NET and its type system. That said…

It seems to me that this is consistent with the goal of reflection providing information about how a type was written. Consider the alternative: what if the PropertyInfo object returned included both the setter from the derived class and the getter from the base class. It would be considerably more difficult to understand from the returned result what was actually declared where, and the PropertyInfo object itself would arguably be inconsistent. This is because there is the PropertyInfo.DeclaringType property which implies that all of the information for the member pertains just to that declaring type.

With members which are neither properties nor events (both of which encapsulate a pair of class members), you get the behavior you expected. Unless of course you pass BindingFlags.DeclaredOnly, which restricts the returned information to the declaring type. But in the case of those types of members, the DeclaringType property tells you unequivocally in which type the member was actually declared.

With a property, the DeclaringType tells you in which class the property was declared. And then the SetMethod and GetMethod properties tell you what that class declared.

IMHO, this makes the reflection API simpler, more consistent, and easier to understand. It does mean that you have to do a little more work to analyze virtual properties. But then, reflection is always going to involve "a little more work". :)