Объекты WPF Sentinel и способы проверки внутреннего типа

Как некоторые из вас обнаружили, появилась новая функция (?) WPF 4, в которой механизм привязки данных может передавать ваши экземпляры настраиваемого элемента управления класса MS. Internal.NamedObject с именем « {DisconnectedItem} » в DataContext - вместо элемента данных, ожидаемого вашим кодом (это происходит, когда шаблонный элемент управления отключается его ItemsControl). Они вызываются объекты-дозорные.

В существующем коде это может привести к ложным исключениям, когда код не подготовлен к этому. Они могут быть поглощены подсистемой привязки данных или могут нанести ущерб. Следите за своей консолью отладки.

Во всяком случае, я узнал об этом на этом форуме MSDN . И там есть сообщение Сэма Бента, который объясняет все . Прочтите это сейчас, вы захотите узнать это . Суть в том, что эти события никогда не должны были запускаться (это ошибка), поэтому:

Игнорируйте событие DataContextChanged, если DataContext является контрольным объектом.

Итак, я хочу проверить свой DataContext. Но как? Подумайте:

public bool IsSentinelObject(object dataContext)
{
    return (dataContext is MS.Internal.NamedObject);
}

Угадайте, что происходит? Он не компилируется, потому что MS.Internal.NamedObject является внутренним и недоступным для меня. Конечно, я могу взломать это так:

public bool IsSentinelObject(object dataContext)
{
    return dataContext.GetType().FullName == "MS.Internal.NamedObject"
           || dataContext.ToString() == "{DisconnectedObject}";
}

(или что-то вроде того, что работает).Я также последовал предложению Сэма о кэшировании объекта для последующих проверок равенства ссылок (это одноэлементный объект).

Конечно, это означает, что у меня нет проблем, на самом деле. Но мне любопытно, и эта публикация обязательно принесет пользу некоторым пользователям, поэтому все равно стоит спросить:

Есть ли способ точно проверить тип по внутреннему типу NamedObject, не прибегая к сравнению строк?