Technology Toolbox

Your technology Sherpa for the Microsoft platform

Jeremy Jameson - Founder and Principal



Debugging Symbols -- They're Not Just for Debug Builds Anymore

This post originally appeared on my MSDN blog:

Since I no longer work for Microsoft, I have copied it here in case that blog ever goes away.

I started another new project this week.

Typically one of the first tasks on any new development project is to create a Development Plan that provides consistent guidelines and processes for the Development team. On this new project, another Microsoft consultant had already created a draft of the Development Plan, but in the process of reviewing it, I added some content from a Development Plan that I had created a few years ago.

In the process of reviewing my old document, I came across the following:



Debug Symbols

All Debug builds should create symbol files for debugging purposes. These symbols are included as part of the setup to facilitate debugging in other environments such as DEV.

Do not include Debug symbols in the Release configuration of the setup projects.

When I read this, I actually let out an audible laugh (okay, I suppose it was more of a chuckle). It must have been the old C++ developer in me that originally put this in the Development Plan (thinking you should never provide PDB files in your Release builds because it makes it all too easy for an outsider to understand your code).

Well, any .NET developer who has ever fired up Reflector on somebody else's assembly (which hasn't been obfuscated, obviously) knows very well how easy it is to decompile -- er, I mean disassemble -- source code. In fact, regardless of whether you have the PDB files, you can actually debug .NET code -- including setting breakpoints and examining variables -- using tools like WinDbg. I've had to do a little of this in the past and while it's not exactly easy -- especially for a developer who doesn't use WinDbg frequently -- it does help out in a pinch when troubleshooting some nasty problem in Production.

However, including debugging symbols (i.e. PDB files) in Release builds certainly makes debugging .NET code easier. This is a key point that John Robbins makes in Debugging Microsoft .NET 2.0 Applications. In fact, here's a direct quote from page 38:

Build All Builds with Debugging Symbols all builds, including release builds, with full debugging symbols. [...]

In other words, the Development Plan should say:

Always include Debug symbols in the Release configuration of the setup projects -- or, preferably, make them available from a symbol server.

Regarding John's book...I strongly recommend this book to anyone who considers himself or herself a "serious developer." It is chock full of great tips and recommendations for developing .NET solutions.


  1. # re: Debugging Symbols -- They're Not Just for Debug Builds Anymore

    January 29, 2010 12:47 AM

    Hi Jeremy,

    You blog is full of real tech. information.

    I was wondering if you can share your Development Plan format to us? Interested in knowing what could make a perfect Development Plan.

    Thanks and keep up the good work!


  2. # re: Debugging Symbols -- They're Not Just for Debug Builds Anymore

    March 10, 2010 4:30 PM
    Jeremy Jameson

    Thanks, Koyalo.

    Ah, the elusive pursuit of the "perfect" documentation...

    Well, I wouldn't say it's "perfect" but here's the table of contents from a Development Plan that I created for a project. This is very similar to the current template provided by the Microsoft Services Delivery Methodology (SDM).

    Table of Contents

    1 Introduction

    1.1 Purpose

    1.2 Audience

    1.3 References

    1.4 Document Conventions

    2 Design Goals, Objectives, Assumptions, and Constraints

    2.1 Goals

    2.2 Objectives

    2.3 Assumptions

    2.4 Constraints

    3 Overall Delivery Strategy

    3.1 Milestone-Based Delivery

    3.2 Breadth-First

    3.3 Features Then Performance

    4 Trade-off Approach

    5 Build and Deployment Overview

    6 Development and Build Environments

    6.1 Developer Environments (LOCAL)

    6.2 Development Integration Environment (DEV)

    6.3 Build Server

    6.4 Source Control Server

    6.5 Release Server

    6.6 Test Environment (TEST)

    6.7 Production Environment (PROD)

    7 Guidelines and Standards

    7.1 Default Language

    7.2 Visual Studio Solutions and Projects

    7.2.1 Fabrikam.Project1 Solution

    7.3 Coding Standards

    7.3.1 Naming Guidelines

    7.3.2 Coding Guidelines

    8 Versioning and Source Control

    8.1 Assembly Versioning

    8.1.1 File Version

    8.1.2 Assembly Version

    8.1.3 AssemblyVersionInfo.cs

    8.2 Source Control

    8.2.1 TFS Project

    8.2.2 TFS Source Control Structure

    8.3 Build Labels

    8.3.1 Source Code

    8.3.2 Setup Files

    8.3.3 Automated Tests

    9 Daily Build Process

    9.1 Check-Ins

    9.2 Automated Build Process

    9.3 Build Scripts

    9.4 Build Verification Tests

    9.4.1 Creation and Ownership

    9.4.2 Test-Driven Development

    9.4.3 Sample Unit Test

    9.4.4 Smoke Tests

    9.4.5 Investigating Failures

    9.5 Build Hand-off

    9.6 Troubleshooting Guide

    10 Installation

    10.1 Setup Packages

    10.2 Debug Symbols

    10.3 Install Batch Files

Add Comment

Optional, but recommended (especially if you have a Gravatar). Note that your email address will not appear with your comment.
If URL is specified, it will be included as a link with your name.

To prevent spam from being submitted, please select the following fruit: Grapes

Please add 4 and 3 and type the answer here: