24

According to msdn http://msdn.microsoft.com/en-us/library/8cw0bt21.aspx , both compilation setting "/debug:pdbonly" and "/debug:full" will make .pdb (Program Database) files be generated.

However, what is the difference?

The page says: "One difference between /debug:pdbonly and /debug:full is that with /debug:full the compiler emits a DebuggableAttribute, which is used to tell the JIT compiler that debug information is available. Therefore, you will get an error if your code contains the DebuggableAttribute set to false if you use /debug:full."

Fine, so this is a possible conflict between the code and the compilation setting, if the code turned DebuggableAttribute to false and compilation set to /debug:full, JIT will get lost.

But is this the only difference between compilation setting "/debug:pdbonly" and "/debug:full" ?

Will there be security issue, if pdb files with "/debug:pdbonly" or "/debug:full" compilation are delivered to end users?

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
athos
  • 6,120
  • 5
  • 51
  • 95
  • 4
    Specifies the type of debugging information generated by the compiler. The full argument, which is in effect if you do not specify /debug:pdbonly, enables attaching a debugger to the running program. Specifying pdbonly allows source code debugging when the program is started in the debugger but will only display assembler when the running program is attached to the debugger. [http://netrsc.blogspot.com/2009/09/debug-option-causes-compiler-to.html] – Anuruddha Nov 04 '11 at 09:24
  • 4
    Re security issues... if the assembly is not obfuscated it is easy to read with or without the pdb etc – Marc Gravell Nov 04 '11 at 09:28
  • The MSDN Library article about it looks borked. Fairly sure that /debug:pdbonly tells the compiler not to put source file name and line number debug info into the .pdb. Makes it smaller. Line number info is not very useful in the Release build since the jitter optimizer moves code around. – Hans Passant Nov 04 '11 at 11:31
  • +1 for @MarcGravell for security risks. With or without debug/release/optimization/pbd/etc. Even with obfuscator you can break the code but it's much much harder. – Anderson Matos Nov 07 '11 at 22:48

0 Answers0