The significance of <> in C#

Question

I\'m studying C# and caught a piece of code that I don\'t understand. I was hoping that you could clearify it for me.

CreateCustomerTask.<>c__DisplayCl         


        

Answer 1

You're looking at some decompiled code - specifically, something that was generated by the compiler.

The compiler uses <> (this is an implementation detail) because, whilst it's valid for a CLR identifier to start with such characters, it's not valid in C# - so it's guaranteed that the name will not conflict with any names in the C# code.

why the compiler has generated this code varies - it can be the implementation of a lambda, or an iterator or async block, and possibly some other reasons also.

---

And, hopefully the other part of your question is also answered - there's a . in front of it for the usual reasons - to separate namespace portions, or more likely in this case, to separate the name of a nested class from the name of the enclosing class.

Answer 2

Use this answer by Eric Lippert to decode names such as <>c__DisplayClass0. According to the table provided in the answer, you are looking at an anonymous method closure class. Do not rely on this always being true in the future, it is an implementation detail subject to change at any time.

Answer 3

As others have pointed out, what you're seeing is a name generated by the compiler that is deliberately not legal C#, so that no one can ever accidentally (or deliberately!) cause a name conflict.

The reason this name is being generated is because;

class C
{
  void M()
  {
    int x = 1;
    Func<int, int> f = y=>x+y;
  }  
}

Is generated by the compiler as though you'd written:

class C
{
  private class DisplayClass
  {
    public int x;
    public int AnonymousMethod(int y)
    { 
      return this.x + y;
    }
  }
  void M()
  {
    C.DisplayClass d = new C.DisplayClass();
    d.x = 1;
    Func<int, int> f = d.AnonymousMethod;
  }
}

Except that of course all the names are deliberately mangled, as you've discovered.

The reason that a closure class is called "DisplayClass" is a bit unfortunate: this is jargon used by the debugger team to describe a class that has special behaviours when displayed in the debugger. Obviously we do not want to display "x" as a field of an impossibly-named class when you are debugging your code; rather, you want it to look like any other local variable. There is special gear in the debugger to handle doing so for this kind of display class. It probably should have been called "ClosureClass" instead, to make it easier to read disassembly.