dotNet 2.0 PDB Files

[Guest]

When deploying a .Net 2.0 library or ASP.Net site we are generating PDB file
to our development and QA environments. Should we remove the PDB files when
deploying to production? The concerns are security and performance.

 

[David Browne]

When deploying a .Net 2.0 library or ASP.Net site we are generating PDB
file
to our development and QA environments. Should we remove the PDB files
when
deploying to production? The concerns are security and performance.

The PDB files assist production debugging by providing additional
information about the source code that is not present in the .NET assembly.
Most importantly the presense of a PDB file will add line numbers to your
exception stack trace.

I don't know of any security or performance implications of deploying these
to a production server environment. For a client deployment the size and
additional IP content of the PDB files may change the equasion. But for any
environment where you expect to be reviewing exception stack traces or doing
production debugging, I would deploy the PDB's too.


David

 

[Guest]

Thanks for your reply but it is my understanding that hooking into the source
code for line numbers and stack trace information would adversely affect the
performance of the application. We would like to provide developers with all
the debugging information possible but not at the cost of performance. Does
anyone know of some benchmarks or knowledge base article that can give me
some hard facts.

 

[Naveen]

The pdb files would be used only if they are required such a
debugger.The runtime wont use pdb files. I dont think pdb symbols would
cause any issues. If you are a library provider then you would probably
want to strip source and line information by generating only public
symbols or else you can probaly use private symbols.