locked
RuntimeReflectionExtensions.GetRuntimeProperties() Malfunction?

    Question

  • I'm building a WP8.1 runtime app using VS2013 Update 4

    RuntimeReflectionExtensions.GetRuntimeProperties() appears not to work as expected. It is documented as follows:

    "This method returns all properties defined on the specified type, including inherited, non-public, instance, and static properties."

    Based on that description, I'd expect this call:

    var info = typeof (ListViewItem).GetRuntimeProperties();

    to return all properties of ListViewItem (including those declared in base classes). The call does in fact return all inherited properties, albeit with one exception. The resulting list omits the ListViewItem.IsSelectedProperty, which ListViewItem inherits from its base class SelectorItem. However, the resulting list includes this property when the call is made directly on the SelectorItem type:

    var info = typeof(ListViewItem).GetTypeInfo().BaseType.GetRuntimeProperties();

    The related methods that retrieve a single PropertyInfo by name exhibit the same behaviour:

    // Returns null
    var info = typeof (ListViewItem).GetRuntimeProperty("IsSelectedProperty");
    
    // Finds and returns the property
    info = typeof(ListViewItem).GetTypeInfo().BaseType.GetRuntimeProperty("IsSelectedProperty");

    Considering that invoking the method on the ListViewItem type does return all inherited properties except for that one exception, and the documentation suggesting there should be no exceptions, the behaviour does seem rather odd.

    Decompiling SelectorItem doesn't reveal anything out of the ordinary, or at least I don't see any anomalies:

    public class SelectorItem : ContentControl, ISelectorItem
    {
      public static DependencyProperty IsSelectedProperty { get; }
    }


      











    Wednesday, December 31, 2014 12:05 AM

Answers

  • I can file a bug on this, but is this affecting your development in any way?

    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Wednesday, December 31, 2014 8:31 PM
    Moderator
  • Hello Matt

    Once understood, it's possible to work around this issue by implementing one's own method that walks up the inheritance tree, calling GetRuntimeProperty(string) on each base type until the desired property is found or the search fails. That is an acceptable workaround, although it performs poorly as it involves a lot of redundant processing, but by no means is it a show stopper.

    Nevertheless, I do think it deserves to be filed as a bug. The method simply doesn't do what the documentation says it should, and the workaround is clunky. The biggest issue is that it cost me two hours to figure out what was actually happening, to be reasonably sure I wasn't overlooking anything, and that the method is in fact behaving incorrectly.

    I'd certainly appreciate it working as specified in a future update.

    Thursday, January 01, 2015 1:25 AM

All replies

  • I can file a bug on this, but is this affecting your development in any way?

    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Wednesday, December 31, 2014 8:31 PM
    Moderator
  • Hello Matt

    Once understood, it's possible to work around this issue by implementing one's own method that walks up the inheritance tree, calling GetRuntimeProperty(string) on each base type until the desired property is found or the search fails. That is an acceptable workaround, although it performs poorly as it involves a lot of redundant processing, but by no means is it a show stopper.

    Nevertheless, I do think it deserves to be filed as a bug. The method simply doesn't do what the documentation says it should, and the workaround is clunky. The biggest issue is that it cost me two hours to figure out what was actually happening, to be reasonably sure I wasn't overlooking anything, and that the method is in fact behaving incorrectly.

    I'd certainly appreciate it working as specified in a future update.

    Thursday, January 01, 2015 1:25 AM