DotNet Reflector — почему я не могу разобрать XmlHierarchicalEnumerable?

Обратите внимание, что ниже приведены примеры редких случаев, когда рефлектор 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)

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


.net c# reflector
person Ben McIntyre    schedule 16.02.2010    source источник

Ответы (4)


arrow_upward
4
arrow_downward

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

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

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

person casperOne    schedule 16.02.2010
comment
Кажется, я помню, как читал, что есть некоторые непечатаемые символы ASCII, которые являются допустимыми идентификаторами CLR, которые можно использовать для кода, сгенерированного компилятором. - person jeffora; 16.02.2010
comment
casperOne: спасибо за это разъяснение. Мне этот код даже не показался внутренне непротиворечивым (например, 'GetEnumerator›d__0'), но я совсем не разбираюсь в правилах CLR, так что это хорошо объясняет. Как и следовало ожидать, я просто декомпилирую .NET 2.0, чтобы обойти некоторые из наиболее серьезных ошибок. Мне надоело делать это по частям, поэтому с помощью FileDisassembler я просто вытащил всю сборку System.Web. Он почти компилируется - есть всего два или три класса, подобных этому, которые мешают этому. Вторым образцом был бренд коммерческих элементов управления UI AJAX (не Telerik, но похожий на них). - person Ben McIntyre; 23.02.2010

arrow_upward
1
arrow_downward

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

person Rohan West    schedule 16.02.2010

arrow_upward
0
arrow_downward

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

person Ravia    schedule 16.02.2010

arrow_upward
0
arrow_downward

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

person Rune FS    schedule 16.02.2010