C# release version has still .pdb file

Question

I want to deploy the release version of my application done in C#.

When I build using the Release config, I still can see that .pdb files are produced, meaning that my application can be still debugged. This also means that some debug information is present somewhere in my code, slowing it down a little bit.

If this is true, how can I completely suppress any debug information produced in the binaries? Do you also know the reason of for having release .pdb? The Release configuration has the Optimize code checked, and only the TRACE constant is defined, not DEBUG.

Thank you for assisting.

@meagar you should keep the .pdb files even for release mode for future reference even if you do not want them to be packaged in the final installer MSI to be sent to the customers. Pdb files will be your only ray of hope when something bursts in an unhandled fashion which causes your application to crash in production boxes. pdb files are very useful to debug crash dump files using winDbg tool that comes with windows SDK. OPTIMIZED code flag should remain checked as you've correctly mentioned. — RBT, Jan 15 '15 at 00:43
Sorry @meagar! I should have addressed Abruzzo Forte instead. Sorry for the inconvenience. It was 6 in the morning and it looks I was still sleepy ;) — RBT, Jan 15 '15 at 09:12

score 111 · Accepted Answer · answered Mar 03 '10 at 12:14

111

If you want to disable pdb file generation, you need to use the "Advanced build settings" dialog available in project properties after clicking the "Advanced..." button" located in the lower part of the Build tab.

Set Output - Debug info: to None for release build configuration and no pdb files will be generated.

answered Mar 03 '10 at 12:14

Marek

10,307
8
70
106

1

You can also use `MSBuild.exe YourProject.csproj /p:DebugSymbols=false /p:DebugType=None` – cowlinator May 17 '18 at 21:11

Brian Rasmussen · Answer 2 · 2014-01-30T21:40:45.560

52

The default is to generate PDBs for release builds as well. That is a feature and you shouldn't disable it. Generating PDBs means you can get more information when debugging. The performance of the code is not affected in any way by the presence of PDB files.

edited Jan 30 '14 at 21:40

answered Mar 03 '10 at 12:16

Brian Rasmussen

114,645
34
221
317

Hi Brian! Thanks! I was skeptical for this, but it seems that everyone agrees on that! – Abruzzo Forte e Gentile Mar 03 '10 at 13:31
So everyone agrees that the PDB files don't decrease performance? Has anyone ran any tests to confirm? – theJerm Nov 24 '13 at 19:37
1

@theJerm the app doesn't read the PDBs during run-time. So apart from the disk space they take up there's no overhead unless you're debugging. – Brian Rasmussen Nov 24 '13 at 19:57
1

@BrianRasmussen: Are PDBs useful in reverse-engineering in any way? I'm obfuscating my release builds. Should I still generate PDBs in the output? – dotNET Feb 21 '17 at 07:27
2

Sorry but I have to disagree, the release build should be exactly that : release, no debugging and not debugging run-time dependencies. – Jamie Nicholl-Shelley Sep 05 '18 at 08:46
unless you are releasing your commercial software of course ;-) – Jakub Míšek May 20 '21 at 14:56

score 19 · Answer 3 · answered Mar 03 '10 at 12:17

19

You don't have to ship the .PDBs with your release deployment, but they are useful to keep around - for example you can remotely debug the code running on a different machine using the PDBs on your machine to get the line numbers of where exceptions occur.

Without the use of the .PDBs, line numbers and file names are not included in stacktraces so it makes it much harder to debug them.

answered Mar 03 '10 at 12:17

Andy Shellam

15,403
1
27
41

Thanks! This was useful! I didn't realize that line number are not present in the StackTrace of each exception object! – Abruzzo Forte e Gentile Mar 03 '10 at 13:27

score 14 · Answer 4 · answered Mar 03 '10 at 13:23

You control pdb / symbol generation in the project properties under Build -> Advanced... -> Debug info:. The options are:

none (no symbol information)
full (a .pdb will be produced, and some symbol information is embedded in the assembly)
pdb-only (a .pdb will be produced but the assembly is not impacted)

See http://msdn.microsoft.com/en-us/library/8cw0bt21%28VS.80%29.aspx for more information.

I strongly recommend that you choose the pdb-only option, not the none option as it still gives you some symbol information without affecting the assembly - you will probably find that this is the current setting you have on your release builds.

score 7 · Answer 5 · answered Mar 03 '10 at 12:12

7

Having the compiler generate a .pdb file is not mutually exclusive to having it optimize the code.

For more info on this subject, read these blog entries.

answered Mar 03 '10 at 12:12

Mehrdad Afshari

414,610
91
852
789

Yes, but embedding debug info in the assembly can also have an impact on performance (according to Microsoft) – Justin Mar 03 '10 at 13:25

score 2 · Answer 6 · answered Aug 04 '22 at 05:25

The compiled EXE file contains the path to the PDB file. The path could easily include your name and is a hint of your file structure. I don't like to share this private information!

In order to remove the path of the PDB file out of the EXE file without loosing debug info, you could embed the PDB file inside the EXE file.

Properties => Build => Advanced (Build Settings) => Debuginfo => Embedded

Damien · Answer 7 · 2023-07-18T05:41:49.643

In the case of a solution with lots of projects, it can be tedious to go to all the different projects settings to disable / enable the pdb file generation.

Alternatively, they can delete them using del /S *.pdb wither from post build command on the main project or from a bat file, which allows you to choose whether to run it or not without having to edit all project files.

From post build event example:

if $(ConfigurationName) == Release del /S $(TargetDir)*.pdb

C# release version has still .pdb file

7 Answers7

Linked

Related