What is the difference between Debug and Release i

Question

Possible duplicate Debug Visual Studio Release in .NET

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

Answer 1

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 VS2010. 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>

Interesting that in the Link section they both have GenerateDebugInformation set to true.

Answer 2

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.

Answer 3

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 can be abused and dramatically change not just the low-levels but the actual business logic.

Answer 4

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.

Answer 5

I don't know what the exact differences are because there is actually no information easily available on that.

But the main observed difference is that release version sometimes corrupts the resulting DLL file and thus makes you application, web application unusable.

Sadly, you have to put debug build in production. And yes, to publish you have to use good old FTP.

Answer 6

The obvious difference you can see is the size of the binary. Debug build produces a larger binary than 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 asses 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.