Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Advantages and disadvantages of including PDB files with your release application

I've got a VB.net application. Currently the release version of the application is produced without a PDB file. This gives me error logs lacking useful details such as line numbers. I'm looking at including the PDB files with future builds but i'd like to know what the advantages and disadvantages of this are (performance wise, size wise, code security wise)

like image 351
zeocrash Avatar asked May 13 '10 09:05

zeocrash


People also ask

Are PDB files needed for release?

PDB files contain debug symbols that allow you to debug your binary even in release mode. You don't have to (and probably shouldn't deploy them), as they might be used to reverse engineer your application.

Why is there a PDB files in release folder?

PDB files help you and the debugger out, making post-mortem debugging significantly easier. You make the point that if your software is ready for release, you should have done all your debugging by then.

Why do we need PDB file?

Program database (PDB) is a file format (developed by Microsoft) for storing debugging information about a program (or, commonly, program modules such as a DLL or EXE). PDB files commonly have a . pdb extension. A PDB file is typically created from source files during compilation.

Do PDB files affect performance?

The executive summary answer: no, generating PDB files will have no impact on performance whatsoever.


2 Answers

I know I'm going to get beat up for this but...

I agree with Dave Markle, but I'd like to add that an advantage of publishing the PDB files is, as you said, VERY nice for debugging.

That said, I don't sell software, and the code I write is all for internal use in our company. In this context, I don't see an issue with putting debug code into production, along with the PDB files. I've never seen a performance hit, and in all honesty, our users rarely give us the right information if they encounter unhandled exceptions. Of course, we try to handle exceptions correctly, but as you know, errors will happen. Our strategy is to add a global exception handler to ALL projects, and log those events tot he database. These errors contain the line numbers because we do include the debug files, and as a result, we are able to quickly identify and react to bad code, fix it, and get more bug-free applications. To me (and to our users) this is a HUGE benefit that I wouldn't want to do without.

So if you're in a similar situation, I say forget the official stance (in this one case) and go ahead and publish the pdb files with ONE important caveat.

Be darn sure that any web application you deploy with the PDB files, be completely sure that ALL exceptions are handled properly, and you're not inadvertently exposing lines of code in a standard Asp.NET error page.

like image 141
David Avatar answered Oct 12 '22 03:10

David


When you deploy your debug symbols for your application, it becomes really easy for someone to come along and reverse-engineer your work, which some people find undesirable. Likewise, you have to deploy more files and your deployable project gets bigger. The PDB files themselves don't cause the app to get any slower, as shipping a PDB doesn't always preclude forgoing optimizations (you just have to be careful -- the default "Debug" project settings tend to not optimize your outputs when they generate PDBs).

like image 35
Dave Markle Avatar answered Oct 12 '22 03:10

Dave Markle