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)
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.
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.
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.
The executive summary answer: no, generating PDB files will have no impact on performance whatsoever.
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.
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With