An educated guess (Timur Fanshteyn): Keep release PDBs to help with debugging production problems

Not many developers know that PDB files are generated during release builds are just as helpful as they are in debug builds.

For some background information, PDB Files contain debugging symbols that are used by .NET Debuggers (including Visual Studio) to lookup source code information. If symbols are available, debugger will be able to show not just the function where exception happened, but also the line number in the source file where exception occurred.

Currently, our current build process copies results of every build into a separate output folder, away from the source code. A new step was just added to make a copy of PDBs into a subfolder as well. Here’s a snippet of XML that I’ve added to the .csproj target

    <CreateItem Include="$(TargetDir)\*.pdb">
      <Output TaskParameter="Include" ItemName="PDBFiles" />
    </CreateItem>
    <Copy SourceFiles="@(PDBFiles)" 
            DestinationFolder="$(OutputPath)\PDB" />

One way to use PDB files is to provide them with your application. If PDB file is available at the time of exception, Exception information will include line numbers and source code file name in the exception.

You can also debug release versions of the executable using Visual Studio. From the Tools menu, select “Attach to Process”, Select your executable. After debugging session starts, In Debug menu, Window->Modules, Right click on the module for your executable, and select “Load Symbols From”. Point to your PDB file, and you are done. It will be important to have source code available if you want to step through. That however is a completely different issue.