DotNet Reflector - why can't I disassemble XmlHierarchicalEnumerable ?

Question

Note that the following are examples of the rare cases where dotNet reflector does not disassemble correctly. In the vast majority of cases it works perfectly, and I am not suggesting this is necessarily a bug in reflector. It may be a result of protection or obfuscation or unmanaged code on the assemblies in question.

I try to disassemble System.Web.UI.WebControls.XmlHierarchicalEnumerable in dotnet reflector. The generics seems all screwed up, eg:

// 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;

In other assemblies I sometimes get little squares (I know these usually stand for 'unknown symbol') in place of class names, eg:

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

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

What gives ? Anyone know ?

Answer 1

In the first example, this is completely expected. These classes are used for the implementation of IEnumerable<T> when using the yield return statements. It generates classes which store the state and get the new values when MoveNext is called on the IEnumerator<T> instance output by the IEnumerable<T> implementation (you will note they are one in the same).

It should be noted that what you are seeing is completely legal naming syntax from a CLR perspective. From a C# perspective though, it is not legal. However, since these classes are internal and you will never need access to them directly (only through interface implmentations), there is no need for them to be legal C# names.

As for the second, I haven't seen that behavior, it's possible that the assembly is obfuscated, but I've not seen that in .NET in any version. If you clarify the assemblies (.NET framework or not) in which version of the .NET framework you are looking at, as well as what version of reflector you are using, it would help.

Answer 2

I have seen this before when looking at assemblies that have been Obfuscated. Quite often during this process variable names are unreadable to the human eye, thus resulting in a unknown character.

Answer 3

This assembly might have been Obfuscated, you can check these links http://cooprotector.com/ http://intelliside.com/

Answer 4

There's quite a few things being autogenetated by the compiler. Auto properties, anonymous types/methods and emumerators based on enumerator blocks. They All need a name and that should be one that does not clash with something names by the developer. Since <>_ is a perfectly legal name in CLR terms but not in C# prefixing anything autogenetated and named with <>_ ensures that the compiler wont accidentally choose a name already used by the developer.