[.net] Release generating .pdb files, why?

Why does Visual Studio 2005 generate the .pdb files when compiling in release? I won't be debugging a release build, so why are they generated?

Actually without PDB files and symbolic information they have it would be impossible to create a successful crash report (memory dump files) and Microsoft would not have the complete picture what caused the problem.

And so having PDB improves crash reporting.

Without the .pdb files it is virtually imposible to step through the production code; you have to rely on other tools which can be costly and time consuming. I understand you can use tracing or windbg for instance but it really depends on what you want to achieve. In certain scenarios you just want to step through the remote code (no errors or exceptions) using the production data to observe particular behaviour, and this is where .pdb files come handy. Without them running the debugger on that code is impossible.

.PDB file is the short name of "Program Database". It contains the information about debug point for debugger and resources which are used or reference. Its generated when we build as debug mode. Its allow to application to debug at runtime.

The size is increase of .PDB file in debug mode. It is used when we are testing our application.

Good article of pdb file.

http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P

In a multi-project solution, you usually want to have one configuration that generates no PDB or XML files at all. Instead of changing the Debug Info property of every project to none, I thought it would be more expedient to add a post-build event that only works in a specific configuration.

Unfortunately, Visual Studio doesn't allow you to specify different post-build events for different configurations. So I decided to do this manually, by editing the csproj file of the startup project and adding the following (instead of any existing PostBuildEvent tag):

  <PropertyGroup Condition="'$(Configuration)' == 'Publish'">
    <PostBuildEvent>
        del *.pdb
        del *.xml
    </PostBuildEvent>
  </PropertyGroup>

Unfortunately, this will make the post build event textbox blank and putting anything in it can have unpredictable results.

PDB can be generated for Release as well as for Debug. This is set at (in VS2010 but in VS2005 must be similar):

Project ? Properties ? Build ? Advanced ? Debug Info

Just change it to None.

Also, you can utilize crash dumps to debug your software. The customer sends it to you and then you can use it to identify the exact version of your source - and Visual Studio will even pull the right set of debugging symbols (and source if you're set up correctly) using the crash dump. See Microsoft's documentation on Symbol Stores.

Debug symbols (.pdb) and XML doc (.xml) files make up a large percentage of the total size and should not be part of the regular deployment package. But it should be possible to access them in case they are needed.

One possible approach: at the end of the TFS build process, move them to a separate artifact.

Why are you so sure you will not debug release builds? Sometimes (hopefully rarely but happens) you may get a defect report from a customer that is not reproducible in the debug version for some reason (different timings, small different behaviour or whatever). If that issue appears to be reproducible in the release build you'll be happy to have the matching pdb.