Question

I'm working on a tool that analyzes code in .NET binaries using Mono.Cecil. As part of this, I'm also checking the .pdb files for the binaries to link findings to source code lines.

This works fine for most cases: I get the right source file path and line number from the .pdb. However, in some cases (I believe when the code is inside a #region, but not sure), the line number is set to 16707566 (0xFEEFEE). This is a lesser-known compiler feature to indicate that the line is hidden from the user. The problem is, when the .pdb contains 0xFEEFEE as the line number, I can't do much with it - I can't (easily) tie my analysis findings back to the source.

I tried to change a number of Visual Studio options and then rebuild the code that I'm analyzing but I'm still getting 0xFEEFEE as line number for code in regions. (For example, I tried disabling regions but it doesn't help. Plus the analyzed code is built from build scripts, not from the IDE.)

Is it possible to tell the C# compiler (perhaps through a .csproj setting or in the registry) to always emit real line numbers (when it makes sense - for 'real' source code lines) and don't use these hidden line markers?

Was it helpful?

Solution

This turned out to be a problem in my code - being inexperienced with PDB files, I assumed that the compiler would output the first sequence point on the first instruction in a method's body. This is not the case: sometimes the compiler generates code for a function that doesn't map directly to original source code so the first 'user' sequence point may not be the first instruction in the method body.

I had to loop through all instructions in method bodies and look for the first sequence point with a meaningful line number - this radically reduced the number of hidden lines I got.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top