Correct understanding of a .NET stack trace with delegates

Question

I'm trying to get a deeper understanding of each frame in a .NET stack trace. Most stack traces are easy to understand. I also know about packages like Ben.Demystifier to make it even more readable. Here's an example of a stack frame I'm trying to understand better:

Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext()

As I understand this, the Microsoft.AspNetCore.Mvc.Controllers part is the namespace, ControllerBinderDelegateProvider is a class, and MoveNext() is a method. What about the <>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d part can someone help explain what this cover?

There are generated .NET nested classes that correspond to higher level C# constructs. You can dig around that using a tool such as ILSpy: https://github.com/icsharpcode/ILSpy — Simon Mourier, Aug 30 '21 at 05:55
Looking in ILSpy, dotPeek, or something similar is a good idea — ThomasArdal, Aug 30 '21 at 06:04
https://stackoverflow.com/questions/16401860/what-does-displayclass-name-mean-when-calling-lambda — Hans Passant, Aug 30 '21 at 10:52

Atif Aziz · Accepted Answer · 2021-08-30T15:39:13.737

The <>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d part is generated by the C# compiler. In the cited case, it is specifically generated for the local function Bind in the method CreateBinderDelegate that belongs to the class ControllerBinderDelegateProvider, and which sits under the namespace Microsoft.AspNetCore.Mvc.Controllers.

To understand the various part of the name, follow GeneratedNames.MakeLocalFunctionName in the compiler/Roslyn source code. It calls the main workhorse method MakeMethodScopedSynthesizedName.

The implementation details may change over time, but for now, here's a rough breakdown of <>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d, which you can see as being composed of several parts:

<>c__DisplayClass0_0
<CreateBinderDelegate>g__Bind|0
<...>d or <<CreateBinderDelegate>g__Bind|0>d

Note that in the third case, the second one is embedded.

All the synthesized names created by MakeMethodScopedSynthesizedName have the following pattern based on parameter names:

"<" methodName? ">" kind
  ( "__" suffix suffixTerminator? )?
  ( methodOrdinal ("#" methodGeneration )?
  | entityOrdinal ("#" entityGeneration )?
  | methodOrdinal ("#" methodGeneration )?
    "_"
    entityOrdinal ("#" entityGeneration )?
  )?

In the above pattern, anything in quotes ("...") is a literal, parentheses ((...)) are used for grouping, ? means optional, | means or, and identifiers like methodName and suffix represent the value of MakeMethodScopedSynthesizedName arguments.

The <>c__DisplayClass0_0 part is generated by a call to GeneratedNames.MakeLambdaDisplayClassName:

MakeMethodScopedSynthesizedName(GeneratedNameKind.LambdaDisplayClass,
                                methodOrdinal, generation,
                                suffix: "DisplayClass",
                                entityOrdinal: closureOrdinal,
                                entityGeneration: closureGeneration);

Since methodName is null, the synthesized name starts with <>, the c comes from GeneratedNameKind.LambdaDisplayClass, the suffix is clearly DisplayClass and the 0_0 comes from assuming that methodOrdinal and generation are zero for that call.

You can follow the sources to see how the other parts are built with a variation of arguments to MakeMethodScopedSynthesizedName, but in brief:

The <CreateBinderDelegate>g__Bind|0 part is generated by a call to GeneratedNames.MakeLocalFunctionName.

MakeMethodScopedSynthesizedName(GeneratedNameKind.LocalFunction, methodOrdinal, methodGeneration, methodName, localFunctionName, GeneratedNameConstants.LocalFunctionNameTerminator, lambdaOrdinal, lambdaGeneration);

The <...>d part is generated by GeneratedNames.MakeStateMachineTypeName where the ... comes from the methodName value:
```
MakeMethodScopedSynthesizedName(GeneratedNameKind.StateMachineType, methodOrdinal, generation, methodName);
```

Correct understanding of a .NET stack trace with delegates

1 Answers1