This project is read-only.

Syntax of Dynamic code in MSIL

Nov 18, 2010 at 8:40 PM

With reference to my last posting about Dyamic and struct types, I disassembled some MSIL using .Net Reflector.  This snippet showed up:


I understand o__SiteContainer0,p__Site2,  but what is the meaning of the syntax <Main>... , and <>p__Site2?  Is that part of C# or just MSIL?



Nov 19, 2010 at 7:17 AM

The names are compiler-generated and not usabe from C# code. Reflector doesn't always disassemble the code with full fidelity. They have yet to implement recognition of dynamic patterns.

Nov 19, 2010 at 3:17 PM
Edited Nov 19, 2010 at 4:45 PM


A similar name is generated by ILDASM.  Stripped of most of it's context resolution it is:


From your answer, I take it this is not some esoteric C# syntax that I missed but instead it is esoteric MSIL syntax.  I don't find a description in Ecma-335 but this document is from 2006 and may be out of date with respect to dynamic extensions.  Or, as you say, it may just be something MS dreamed up for ILDASM and Reflector picked up on.

So I will make a stab at what it means.  Anyone who knows better, please correct me.

The syntax Program/TypeName is a nested type resolution, i.e. class  "TypeName" is defined withing class "Program"

Implying from the usage, <Main>o__SiteContiner0 is an object of a class constructed on the fly, associated with function Main.   It almost looks like a generic but in MSIL, generics should have an integer preceding the '<' indicating the number of generic parameters. 

<>p__Site1 is a reference  to a member of that class, in this case a call site delegate, a.k.a function pointer.  I don't know what the <> means or why it is empty. 



Nov 19, 2010 at 3:22 PM

It's not esoteric syntax at all; it's just a name. The C# compiler needs to generate a name that's both unique and guaranteed not to collide with any user-defined names. The algorithm probably works something like what you describe, but it's really just an internal implementation detail of the compiler, one that you should certainly not depend on. The reason for the odd symbols is that they're not valid in C# identifiers, so there won't be a collision with user-defined names.