DotNet Reflector - почему я не могу разобрать XmlHierarchicalEnumerable? - PullRequest
2 голосов
/ 16 февраля 2010

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

Я пытаюсь разобрать System.Web.UI.WebControls.XmlHierarchicalEnumerable в отражателе dotnet. Дженерики, кажется, все облажались, например:

// Nested Types
[CompilerGenerated]
private sealed class GetEnumerator>d__0 : IEnumerator<object>, 
    IEnumerator, IDisposable
{
    // Fields
    private int <>1__state;
    private object <>2__current;
    public XmlHierarchicalEnumerable <>4__this;
    public IEnumerator <>7__wrap2;
    public IDisposable <>7__wrap3;
    public XmlNode <node>5__1;

В других сборках я иногда получаю маленькие квадраты (я знаю, что они обычно означают «неизвестный символ») вместо имен классов, например:

    dictionary1.Add("autopostbackonselect", 0x34);
    ᜀ.ᜌ = dictionary1;
}

if (ᜀ.ᜌ.TryGetValue(key, out num))
{
    switch (num)

Что дает? Кто-нибудь знает ?

Ответы [ 4 ]

4 голосов
/ 16 февраля 2010

В первом примере это вполне ожидаемо. Эти классы используются для реализации IEnumerable<T> при использовании операторов yield return. Он генерирует классы, которые хранят состояние и получают новые значения, когда MoveNext вызывается на выходе экземпляра IEnumerator<T> реализацией IEnumerable<T>.GetEnumerator ( Вы заметите, что они одно и то же).

Следует отметить, что то, что вы видите, является абсолютно легальным синтаксисом именования с точки зрения CLR. С точки зрения C #, это не законно. Однако, поскольку эти классы являются внутренними, и вам никогда не понадобится доступ к ним напрямую (только через имплементации интерфейса), им не нужно быть допустимыми именами C #.

Что касается второго, я не видел такого поведения, возможно, что сборка запутана, но я не видел этого в .NET ни в одной версии. Если вы укажете сборки (платформа .NET или нет), в какой версии платформы .NET вы просматриваете, а также какую версию отражателя вы используете, это поможет.

1 голос
/ 16 февраля 2010

Я видел это раньше, когда смотрел на сборки, которые были запутаны . Довольно часто во время этого процесса имена переменных не читаются человеческим глазом, что приводит к появлению неизвестного символа.

0 голосов
/ 16 февраля 2010

Компилятор автоматически генерирует несколько вещей. Авто свойства, анонимные типы / методы и эмуляторы на основе блоков перечислителей. Всем им нужно имя, и это должно быть то, что не противоречит именам разработчиков. Поскольку <> _ является совершенно допустимым именем в терминах CLR, но не в C #, с префиксом чего-либо, автоматически сгенерированного и названного с помощью <> _, гарантирует, что компилятор не выберет случайно имя, уже используемое разработчиком.

0 голосов
/ 16 февраля 2010

Эта сборка могла быть запутана, вы можете проверить эти ссылки http://cooprotector.com/ http://intelliside.com/

...