views:

1968

answers:

11

Do you have to deploy the .pdb file with compiling under release?

Why does it even compile a .pdb when you do a release build anyway?

+2  A: 

If you want, you can also turn the PDB file generation off in the compile options.

NYSystemsAnalyst
A: 

No, you don't have to deploy the .pdb file.

To quote from MSDN, "A PDB file is created when you build with /debug (Visual Basic/C#).", so it shouldn't be creating the debug database when compiling for release.

Alex Fort
A: 

No, you don't ship the .pdb files. They are generated because sometimes it's helpful to be able to debug a release build.

zildjohn01
+14  A: 

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

  1. Debugging
  2. Profiling

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 :(

JaredPar
Now I'm curious. How are PDB's used in profiling?
Dan Esparza
@Dan, Part of profiling is being able to map random places in your assembly back to user code. Otherwise you wouldn't know what code was excercised just what assembly. PDB's are great for mapping assembly -> source (this is one of the reasons a debugger needs them)
JaredPar
OK -- I guess I would consider that part of debugging. ;-) I thought you meant some sort of performance analysis of release code.
Dan Esparza
@Dan, profiling is performance analysis. It is just useless unless it can map assembly back to the code you actually compiled. This is where the PDB comes in.
JaredPar
+1  A: 

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.

Dan Esparza
A: 

Some tools like AVICode's InterceptStudio use the pdb files to view the source of a particular exception/stack trace/local from within the tool, rather than having to open up the source and go to a specific line.

TheMissingLINQ
+2  A: 

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.

Yuliy
A: 

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.

Assaf Lavie
A: 

you don't need them to run. pdb files can be used to debug even if the build is on release configuration.

Chen Kinnrot
+3  A: 

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.

Kovey
A: 

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.

PaulJ
actually, they can easily send you a memory dump (doesn't even have to be a full one, any windows PC can generate one) which will at least tell you the entire callstack and usually the variables passed into the top-most function call
Grant Peters