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

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

Я пытаюсь разобрать систему.Сеть.ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС.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 2
c# .net reflector

4 ответа:

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

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

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

4

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

1

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

0

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

0