使用 Rhino ETL 出现在调试器本地窗格中的内部编译器变量
如果反汇编 C#，您经常会看到编译器插入的临时变量，其名称如下：
CS$1$0000
但是什么会导致它们出现在调试器本地/自动窗格中？
我的一位同事正在尝试维护一个使用 编写的工具犀牛 ETL。调试器报告其程序集的符号已正确加载。他可以单步调试代码。但它并没有在调试器中显示他的变量，而是只显示内部编译器生成的变量。
我建议他尝试使用相同的代码编写一个新的控制台应用程序，并替换名为 AbstractOperation 和 Row 的虚拟类以满足编译器的要求（这些是来自 Rhino ETL 库的类） 。当他尝试这样做时，删除了对 Rhino ETL 的所有依赖，在调试器中看到他自己的变量时，一切都恢复正常。
他还尝试在同一解决方案中从源代码构建 Rhino ETL，但这并没有解决问题。显然，这不是由于版本不兼容造成的。
他的代码位于迭代器方法内，因此编译器需要对代码进行重大重组。但迭代器方法通常不会破坏调试器！
在这种情况下，如果它是一个override迭代器方法并且基类是来自Rhino ETL的AbstractOperation，它似乎会破坏调试器图书馆。
基类如何对调试器产生如此大的影响？
If you disassemble C# you often see temporary variables inserted by the compiler with names such as:
CS$1$0000
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
显然 PostSharp 也参与其中，它重写了 IL，当删除对 PostSharp 的依赖时，问题就消失了。谜团解开了。
Apparently PostSharp was also involved, which rewrites the IL, and when the dependency on PostSharp was removed, the problem went away. Mystery solved.