dotNet 2.0 PDB Files

14 Apr 2006 3:53 PM

Ruckus

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.

14 Apr 2006 5:21 PM

David Browne

"Ruckus" <Ruc***@discussions.microsoft.com> wrote in message
news:1FCC56D4-78A8-4837-B834-C02CC3BD3D68@microsoft.com...
> 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

16 Apr 2006 9:47 PM

Ruckus

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.

Show quote

"David Browne" wrote:

>
> "Ruckus" <Ruc***@discussions.microsoft.com> wrote in message
> news:1FCC56D4-78A8-4837-B834-C02CC3BD3D68@microsoft.com...
> > 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
>
>
>

17 Apr 2006 12:48 AM

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.