What is the purpose of the methods in System.Reflection.RuntimeReflectionExtensions?

Question

Since .NET 4.5 (2012), some new extension methods show up, from System.Reflection.RuntimeReflectionExtensions class. However, the new methods do not seem to give us anything new. An example:

static void Main()
{
    var prop1 = typeof(string).GetProperty("Length");
    var prop2 = typeof(string).GetRuntimeProperty("Length");  // extension, needs: using System.Reflection;
    Console.WriteLine(prop1 == prop2);

    Action a = Main;
    var meth1 = a.Method;
    var meth2 = a.GetMethodInfo();  // extension, needs: using System.Reflection;
    Console.WriteLine(meth1 == meth2);
}

This writes True twice.

(The == operator is overloaded here, but even checking for reference equality with (object)prop1 == (object)prop2 and (object)meth1 == (object)meth2 gives True).

So what is the purpose of these new publicly visible methods? Clearly I must be overlooking or misunderstanding something.

I also don't know why these methods are exist, because internally `GetRuntimeProperty` just executes the same `type.GetProperty(name)` method — Sergey Litvinov, Mar 19 '14 at 11:01
I see no purpose. It is completely redundant. If you look at the decompiled code, you will see how pointless they are. Guess someone was asleep the day that got into the codebase. — leppie, Mar 19 '14 at 11:05
This needed to be added to support WinRT. Which is COM based, it doesn't support reflection. A lot of the quirks are hidden by the language projection built into the CLR to hide the fundamentally type system. Nothing very subtle, a string is a *very* different type in WinRT. But it isn't perfect, not exactly sure how they emulate it. — Hans Passant, Mar 19 '14 at 11:16
@HansPassant: Why not provide the functionality via the 'original' places then? Or do these properties/methods not exists there in the first place? And if so, see first question! — leppie, Mar 19 '14 at 11:23
Not sure what 'original' places might be. Sergey's observation is not accurate, that's only true for the desktop version of .NET. If you target WinRT then you work with a completely different set of reference assemblies. Which use tricks with [TypeForwardedTo] to remap types to a completely different implementation. Something like that, digging through this is several hours of my life I'll never get back. It will probably hit a wall on an internal QCall function whose source I can't get to. Rest assured that nobody was asleep when they did this. — Hans Passant, Mar 19 '14 at 11:39

score 1 · Answer 1 · answered Mar 19 '14 at 22:17

1

The GetRuntime* methods are used for WinRT projects. Because the types used by WinRT may be different than the types used by .NET, but still function the same and have the same name, these reflection methods ensure that the correct MemberInfo is returned. You don't likely want a .NET MemberInfo at runtime if you're running WinRT.

See Hans Passant's comment on the original question.

answered Mar 19 '14 at 22:17

Michael Hoffmann

2,411
2
24
42

2

How would these extension methods be useful for that? Who would use these extension methods, and who would use the "old" instance members on `System.Type` etc.? If WinRT needs special behavior because of its type system, why doesn't it just provide special overrides of `Type.GetProperties(BindingFlags)` abstract method, and so on? They could implement non-virtual members differently too if they wished. In short, I can't see how the extensions are useful. Downvoting. – Jeppe Stig Nielsen Mar 20 '14 at 09:16
3

If I look at [`System.Type` documentation](http://msdn.microsoft.com/en-us/library/system.type.aspx) under "Version information", it does include *.NET for Windows Store apps*. If I look at `abstract` methods like [`GetPropertyImpl`](http://msdn.microsoft.com/en-us/library/system.type.getpropertyimpl.aspx) or [`GetProperties(BindingFlags)`](http://msdn.microsoft.com/en-us/library/kyaxdd3x.aspx), they are absent in *.NET for Windows Store apps*. So why don't they just include the instance methods they need, in `System.Type`, instead of creating extensions? – Jeppe Stig Nielsen Mar 20 '14 at 09:48
It could be strict rules to ensure backward compatibility. Here are two possible conflicts: 1) a code with his own GetRuntimeField extension method for Type, 2) a code who would reflect Type and depend on its members ordering. – Victor Victis Sep 15 '14 at 13:27

What is the purpose of the methods in System.Reflection.RuntimeReflectionExtensions?

1 Answers1