What is the difference between Debug and Release in Visual Studio?

> Possible duplicate > https://stackoverflow.com/questions/90871/debug-vs-release-in-net

What is the difference between Debug and Release in Visual Studio?

The most important thing is that in Debug mode there are no optimizations, while in Release mode there are optimizations. This is important because the compiler is very advanced and can do some pretty tricky low-level improving of your code. As a result some lines of your code might get left without any instructions at all, or some might get all mixed up. Step-by-step debugging would be impossible. Also, local variables are often optimized in mysterious ways, so Watches and QuickWatches often don't work because the variable is "optimized away". And there are multitudes of other optimizations too. Try debugging optimized .NET code sometime and you'll see.

Another key difference is that because of this the default Release settings don't bother with generating extensive debug symbol information. That's the .PDB file you might have noticed and it allows the debugger to figure out which assembly instructions corresspond to which line of code, etc.

"Debug" and "Release" are actually just two labels for a whole slew of settings that can affect your build and debugging.

In "Debug" mode you usually have the following:

• Program Debug Database files, which allow you to follow the execution of the program quite closely in the source during run-time.
• All optimizations turned off, which allows you to inspect the value of variables and trace into functions that might otherwise have been optimized away or in-lined
• A _DEBUG preprocessor definition that allows you to write code that acts differently in debug mode compared to release, for example to instrument ASSERTs that should only be used while debugging
• Linking to libraries that have also been compiled with debugging options on, which are usually not deployed to actual customers (for reasons of size and security)

In "Release" mode optimizations are turned on (though there are multiple options available) and the _DEBUG preprocessor definition is not defined. Usually you will still want to generate the PDB files though, because it's highly useful to be able to "debug" in release mode when things are running faster.

Mostly, debug includes a lot of extra information useful when debugging. In release mode, this is all cut and traded for performance.

If you go through project compile options and compare them, you'd see what are the differences.

Assuming the question is about native/C++ code (it's not entirely clear from the phrasing):

Basically, in Debug all code generation optimizations are off. Some libraries (e.g. STL) default to stricter error checking (e.g. debug iterators). More debugging information is generated (e.g. for "Edit and Continue"). More things are generated in code to catch errors (local variable values are set to an uninitialized pattern, and the debug heap is used).

It's probably worth mentioning the very obvious, that build flags allow for different logic which should be used just to change logging and "console" messaging, but it can be abused and dramatically change not just the low-levels, but the actual business logic.

Also note that when using MFC for example, debug projects link against non-redistributable DLL versions like MFC90D.DLL while release builds link against the redistributable versions like MFC90.DLL. This is probably similar to other frameworks.

Therefore you will probably not be able to run debug-build applications on non-development machines.

Also, apparently, Debug mode creates a lot of extra threads to help with debugging. These remain active throughout the life of the process, regardless of whether you attach a debugger or not. See my related question here.

I got curious on this question too when I had developed an application copied from an existing Release build configuration.

I have a developer who is interesting in using that application in debug mode, so I wondered what it would take to make this build configuration that exists with a name of ReleaseMyBuild copied from a Release configuration (and thus should have all settings geared to release optimizations) to suddenly change teams and become a debug build despite the confusing build configuration name.

I figured the project configuration was just a name and a convenient way to select the "whole slew of settings" Joris Timmermans mentions. I wanted to know the nitty-gritty of just what those settings may be that make a build configuration named "FOO" function as an optimized release build.

Here's one glimpse into it. I created a new VCXPROJ from the empty project template from Visual Studio 2010. I then copied it and edited both, the first to retain the debug contents and the second the release contents. Here's the diff centered upon the relevant differences...

RELEASE

<PropertyGroup>
    <WholeProgramOptimization>true</WholeProgramOptimization>

<ClCompile>
    <Optimization>MaxSpeed</Optimization>
    <FunctionLevelLinking>true</FunctionLevelLinking>
    <IntrinsicFunctions>true</IntrinsicFunctions>
<Link>
    <EnableCOMDATFolding>true</EnableCOMDATFolding>
    <OptimizeReferences>true</OptimizeReferences>

DEBUG

<PropertyGroup>
    <UseDebugLibraries>true</UseDebugLibraries>`

<ClCompile>
    <Optimization>Disabled</Optimization>

It is interesting that in the Link section they both have GenerateDebugInformation set to true.

The obvious difference you can see is the size of the binary. A Debug build produces a larger binary than a Release build.

When compiling in Debug, the symbol table is added to the compiled object of the code file which allows for debugging programs to tap into these binaries and access the values of objects and variables.

Another observable difference is that, in Release mode, the binary would simply crash on a fatal error while in Debug mode, if you start debugging the application in Visual Studio, you can check the call stack which tells you the exact location of the erroneous statement.

> In debug configuration, your program compiles with full symbolic debug > information and no optimization. Optimization complicates debugging, > because the relationship between source code and generated > instructions is more complex. > > The release configuration of your program has no symbolic debug > information and is fully optimized. For managed code and C++ code, > debug information can be generated in .pdb files, depending on the > compiler options that are used. Creating .pdb files can be useful if > you later have to debug your release version.

Reference Microsoft doc.

In debug configuration, your program compiles with full symbolic debug information and no optimization. Optimization complicates debugging, because the relationship between source code and generated instructions is more complex.

The release configuration of your program has no symbolic debug information and is fully optimized. For managed code and C++ code, debug information can be generated in .pdb files, depending on the compiler options that are used. Creating .pdb files can be useful if you later have to debug your release version.