1

So we are building a .NET project in our company and it requires us to save the PDBs of each release for debugging purposes in the future. We have this idea to optimize the space requirements. Instead of storing all the PDBs in the newer releases we thought of storing only the PDBs of the modified DLLs from the previous release and later retrieve the unchanged PDBs from the previous archives. So is it feasible to store only the PDBs of the modified DLLs and will the PDBs of the unchanged DLLs match the newer DLLs after the build?

I read in an online article that a unique GUID is generated between the DLLs and the PDBs to determine the match. Is this GUID unique for each build? (even for the unchanged DLLs)

Raja Shekar
  • 65
  • 7
  • 1
    *"optimize the space requirements"* - doesn't sounds realistic. How much are you going to save? Just store both files for each release: dll + pdb. Btw, how about [xml](https://stackoverflow.com/q/4015018/1997232)? – Sinatr Jun 15 '20 at 05:51
  • There are a lot of bug fixes being done regularly and for each build we require about 50mb which may mount up to 2gb in a month sometimes. It is just a proposition by our team leader so we are still thinking about it. And coming to the xml files. I have less info from the development team about this but I guess that we delete them as well once the MSI is created and shipped to the customer. Is the xml file useful in this situation in any way? – Raja Shekar Jun 15 '20 at 06:14
  • Further reading https://www.wintellect.com/pdb-files-what-every-developer-must-know/ Pdbs are dlls are matched by guid, written after every build – Pavel Anikhouski Jun 15 '20 at 08:15
  • yeah thank you @PavelAnikhouski for the reference. Got my answer. – Raja Shekar Jun 15 '20 at 08:32

2 Answers2

1

The answer to your question is No. The dlls and their corresponding pdbs are linked together by timestamp and checksum (or similar). Each new build creates new pdbs, and they won't match the old ones (and VS won't accept them as matching). Note that any two builds of the same dll will be binary different, even if the source code did not change at all, since they also contain timestamps and similar dynamic information.

PMF
  • 14,535
  • 3
  • 23
  • 49
1

No, it won't work. And beside, even if it would, there is the serious drawback that it introduces additional work and potential for error when programmers have to retrieve PDB for debugging.

In the end that are only 240 GByte additional space for 10 years according to your monthly estimate. It's not worth the effort. Think about it: assume a programmer would work a few hours to write, test and deploy a script or something similar to save space (with another method). The harddisc is probably cheaper than paying for the work.

Maybe enable compression on NTFS level, this can save a bit more space and requires hardly any setup work.

Matt
  • 164
  • 1
  • 7
  • Yeah thank you so much for your feedback. I will relay this back to my team leader as well and will work on compressing them more at the NTFS level itself. – Raja Shekar Jun 15 '20 at 08:30