Why isn't LocalBuilder.SetLocalSymInfo emitting variable names?

Question

I tried running the sample code which appears on the documentation page for the System.Reflection.Emit.LocalBuilder class but it appears that the calls to LocalBuilder.SetLocalSymInfo(string, int, int) aren't doing anything since the IL Dissasembler shows this as the IL for SampleAssembly.dll:

.method public static string  Function1(int32 A_0) cil managed
{
  // Code size       10 (0xa)
  .maxstack  1
  .locals init (string V_0,
           int32 V_1)
  IL_0000:  ldarg.0
  IL_0001:  stloc.1
  IL_0002:  ldstr      "string value"
  IL_0007:  stloc.0
  IL_0008:  ldloc.0
  IL_0009:  ret
} // end of method Example::Function1

Why aren't the variable names (myString and myInt) listed in the Dissasembler?

Enviroment Info:

• Windows 7 64 bit
• Visual Studio 2010 Professional SP1
• .Net 4.0.30319 SP1
• Target Framework: .Net 4 Client Profile
• Debug configuration (for the program using System.Reflection.Emit)

Edit: As I noted in a comment, there is a SampleAssembly.pdb file being generated along with the SampleAssembly.dll file.

Answer 1

The debugging support in System.Reflection.Emit is pretty poor and quirky (and to a certain extent this is also true for IKVM.Reflection, because it inherits some of the brokenness from the underlying .pdb writer API that has to be used since the .pdb file format is not documented).

Anyway, the reason the sample doesn't work is that it is missing the following code:

ISymbolDocumentWriter doc = myModule.DefineDocument("sourcefile", Guid.Empty, Guid.Empty, Guid.Empty);

myMethodIL.MarkSequencePoint(doc, 1, 0, 1, 0);

There must be at least a single sequence point in the method, because that is the way the internal data structures are tied together.

Answer 2

Symbol names are stored in the PDB file and not in the assembly.

A tool like Reflector.NET will load the PDB file if present to give your disassembled code better names.

You can also verify this by debugging the code in a debugger with and without the PDB file.

Answer 3

I suspect this is because you are building the module as a release DLL.

Try passing true as the second parameter to AssemblyBuilder.DefineDynamicModule