Internal compiler variables appearing in the debugger Locals pane with Rhino ETL

If you disassemble C# you often see temporary variables inserted by the compiler with names such as:

CS$1$0000
开发者_如何学JAVA

But what would cause them to appear in the debugger Locals/Auto panes?

A colleague of mine is trying to maintain a tool written using Rhino ETL. The symbols for his assembly are reported as loaded correctly by the debugger. He can step through the code. But instead of showing his variables in the debugger, it only shows the internal compiler-generated ones.

I suggested he try writing a new console app with the same code in and substituting dummy classes called AbstractOperation and Row to satisfy the compiler (those are classes from the Rhino ETL library). When he tried that, removing all dependencies on Rhino ETL, everything was back to normal in terms of seeing his own variables in the debugger.

He also tried building Rhino ETL from source in the same solution, but that did not fix the problem. So apparently it's not due to a version incompatibility.

His code is inside an iterator method, hence the need for significant reorganising of the code by the compiler. But an iterator method doesn't usually break the debugger!

In this case, it seems that it will break the debugger if it is an override iterator method and the base class is AbstractOperation from the Rhino ETL library.

How can a base class have such an effect on the debugger?

Apparently PostSharp was also involved, which rewrites the IL, and when the dependency on PostSharp was removed, the problem went away. Mystery solved.