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.

Klapp

@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. – Linguistics

@RasikBihariTiwari I don't care. I didn't ask the question. – Heartily

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 ;) – Linguistics

Answer 1

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.

Shererd

You can also use MSBuild.exe YourProject.csproj /p:DebugSymbols=false /p:DebugType=None – Jin

Answer 2

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.

Sextuplet

Hi Brian! Thanks! I was skeptical for this, but it seems that everyone agrees on that! – Klapp

So everyone agrees that the PDB files don't decrease performance? Has anyone ran any tests to confirm? – Conrado

@Conrado 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. – Sextuplet

@BrianRasmussen: Are PDBs useful in reverse-engineering in any way? I'm obfuscating my release builds. Should I still generate PDBs in the output? – Precaution

Sorry but I have to disagree, the release build should be exactly that : release, no debugging and not debugging run-time dependencies. – Reimers

unless you are releasing your commercial software of course ;-) – Airframe

Answer 3

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.

Joyjoya

Thanks! This was useful! I didn't realize that line number are not present in the StackTrace of each exception object! – Klapp

Answer 4

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.

Schargel

Answer 5

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.

Kreitman

Yes, but embedding debug info in the assembly can also have an impact on performance (according to Microsoft) – Schargel

Answer 6

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

Hammurabi

Answer 7

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

Innsbruck

Answer 8

I added this property group to my SDK style .csproj:

<PropertyGroup Condition="$(Configuration.Contains('Release')) ">
    <DebugType>none</DebugType>
</PropertyGroup>

It is not generating .pdf files for any configuration that contains string Release.

Vittle