Advantages and disadvantages of including PDB files with your release application

Question

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)

Answer 1

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).

Answer 2

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.

Answer 3

I find it useful to also have debug information built for the Release version - it helps with catching bugs. It doesn't make the program run slower. But you shouldn't ship the PDB file with your application, if you don't want others to be able to reverse-engineer it more easily. Only give it to testers.

Answer 4

Create pdbs for your release build, but do not ship them. Keep the pdbs somewhere safe with the matching build and source code. If you get a live crash, or similar, you can use the pdbs to do post-mortem debugging using the Debugging Tools for Windows, or Visual Studio.