32

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__DisplayClass0 cDisplayClass0 =
         new CreateCustomerTask.<>c__DisplayClass0();

What does the <> signify? And why is there a . (dot) in front of it?

sharptooth
  • 167,383
  • 100
  • 513
  • 979

3 Answers3

39

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.

Damien_The_Unbeliever
  • 234,701
  • 27
  • 340
  • 448
  • 1
    "*possibly some other reasons also*" - I would imagine generic declarations would compile down to something similar – James Dec 30 '12 at 14:32
  • 2
    @James - not sure what you're getting at here. Generics are a first class concept in the CLR. Lambdas, iterator blocks, etc, are compiler tricks that produce additional code that needs to go into classes. – Damien_The_Unbeliever Dec 30 '12 at 14:35
  • I am saying that when generic code is compiled down it would possibly produce similar code to what the OP is referring to. – James Dec 30 '12 at 14:50
  • 2
    @James, it is conceivable that it could, but in fact, the IL representation of generic types looks rather different. Notably, there are no `<>` characters involved. – phoog Dec 30 '12 at 15:17
34

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.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
10

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.

Community
  • 1
  • 1