Menu
It is used when we are testing our application. Good article of pdb file. "No need of this file when release or deploy" except when someone experiences a crash in that released version, and the crash report you get from them doesn't contain a usable stack trace... then you'll wish you included it after all.
Shipping pdb does not give any additional convenience to an user. So there are no reasons to ship pdb files with the app. Besides pdb file usually has a large size. Instead of shipping pdb files you should use a local Microsoft Symbol Server for a fast access to pdb files corresponding to error reports.
The easiest way to use the PDB file is to let Visual Studio do the heavy lifting - either launch your program with Visual Studio's "Debug" command (F5 by default), or run the program and use the "Attach to Process" item in Visual Studio's Debug menu.
You can now debug your release build application. To find a problem, step through the code (or use Just-In-Time debugging) until you find where the failure occurs, and then determine the incorrect parameters or code.
No you do not need to deploy them.
As to why they are even built in release. A PDB file really has a couple of uses but the primary ones (at least for me) are
Both of these tasks are validly done on release binaries which is why release builds include a PDB. In fact, when debugging Watson dumps it's 100% of the time against a release build. Without a PDB I would have to resort to looking through dissasembly :(
You don't have to deploy and distribute the PDB files along with your binaries.
However, I suggest that you keep them (and eventually index them) to be able to analyze any dump files that clients, QA, and support people send you. This way, you will be able to have comprehensible stack traces and symbol information.
If you want, you can also turn the PDB file generation off in the compile options.
a PDB file contains information about names of functions. You need it to be able to get a stack trace. It can also contain information about mapping it to sources. Sometimes you might want to ship your release version, and still need to analyze a crash that occurs on the client side. For that, the PDB is needed. The PDB when compiling for release should in theory have less information than when compiling for debug.
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. Do keep them archived somewhere, though, because they come in very handy when you want to debug a crash dump.
Nope. You don't need to distribute them. It'll help with debugging (or I should say it will make debugging possible for sane people).
You can also turn off or adjust the 'level' of symbols generated in Visual Studio -- just go to Project Properties / 'Build' tab / 'Advanced' -- and make adjustments to the 'Debug info' field.
As the majority of the people on this thread have said: no, you don't have to ship the PDB file(s); but really you should if you ever intend to release the code into the wild.
It's really about being able to support your application. Without the PDB, when you application crashes, all your user will be able to tell you is the raw memory address of where the application crashed; but with the PDB file you get an error you can actually do something about.
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