0

There's some conflicting info on the web regarding best practices when it comes to handling .pdb files, and I would be grateful for a clarification.

For example, this source says that "PDB files are as important as source code", while this says .pdbs don't belong into source control.

  1. Should .pdb files generated by build during normal development (debug mode) be committed to source control?
  2. Should only .pdb files used for release/production be stored in source control?

I'd expect the answer to the first question to be "no" and the answer to the second one to be "yes", but I may be missing something.

w128
  • 4,680
  • 7
  • 42
  • 65
  • 2
    I think this will be a matter of opinion. I wouldn't put them into source control, since they're not sources. I would store them with the released versions, though. – Sami Kuhmonen Dec 15 '15 at 16:13
  • 1
    You'll need to use whatever procedure necessary to ensure that you can debug a minidump you get back from the customer. A minidump is the only way to diagnose a difficult crash that you can't repro. That does require having the appropriate executables and matching PDBs, you'll have a very hard time if they don't match or have the wrong timestamp. Setting up a source server is best, a copy on a trustworthy build server can work, source control is not entirely wrong. – Hans Passant Dec 15 '15 at 17:04

3 Answers3

1

PDB files should not go in source control. They are part of the build artifacts and should be kept along with the output from the build (as opposed to discarded after the build). Historical builds should be kept and the version of the currently released deployment should be tracked so if you need to you can pull the PDBs from the corresponding archived build.

Craig W.
  • 17,838
  • 6
  • 49
  • 82
1

In addition to Craig W. s correct answer:

besides the sourceControl System (such as svn/git) you als should also use a build system to archive any builds.

A nice Build System is Jenkins, it's quiet a easy to understand build system with all features i expect. if u distribut your software you login to jenkis and hit "build now". Jenkins then checks out the current version from svn/git and builds your software (using a batch) and saves all Files including the debug/symbol files. jenkins should increase the build number of the binary each time and the build number should be set into the binary file (dll and exe). On a crash u then see the version in the event-viewer and can get all the files from the crashed version including the source.

I also would suggest to write the jenkins build number into the binary. thus you always can logonto jenkins select the build number and you then get all the debug files and also see in the logs what svn version it was built from (thus u can also checkout the proper sourcecode). for Versioning dll or exe files you can use (in .net edit the config file with a script instead): http://www.codeproject.com/KB/install/VerPatch.aspx?msg=3207401 and integrate it in the build batch.

And here you find the jenkins: https://jenkins-ci.org/

Marcel Haldemann
  • 671
  • 6
  • 11
0

See this post on SO. You don't need to add the *.pdb file to source control. These files are generated when you start a new debug session.

Community
  • 1
  • 1
Rhapsody
  • 6,017
  • 2
  • 31
  • 49