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.

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

Well, it depends on what language you are using, but in general they are 2 separate configurations, each with its own settings. By default, Debug includes debug information in the compiled files (allowing easy debugging) while Release usually has optimizations enabled.

As far as conditional compilation goes, they each define different symbols that can be checked in your program, but they are language-specific macros.

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

In Debug Mode your .exe has debug information inside of it (source code, variable names and other similar stuff like that).

In Release Mode your .exe lack of debug information makes it smaller and probably performs better due to its smaller footprint.

Debugging in .NET in Release mode

You can debug in Release mode to an extent. Debug and Release are simply build configurations (of which you can create many), the real difference is that Debug configuration doesn't optimize the generated binary code (optimized code complicates debugging). It also generates additional debug data which release does not.

Debug vs. release in .NET

"Debug" and "Release" are just names for predefined project configurations defined by Visual Studio.

To see the differences, look at the Build Tab in Project Properties in Visual Studio.

The differences in VS2005 include:

DEBUG constant defined in Debug configuration
Optimize code enabled in Release configuration

as well as other differences you can see by clicking on the "Advanced" button

But you can:

Change the build settings for Debug and Release configurations in Project Propeties / Build
Create your own custom configurations by right-clicking on the solution in Solution Explorer and selecting Configuration Manager

I think the behaviour of the DEBUG constant is fairly clear (can be referenced in the #if preprocessor directive or in the ConditionalAttribute). But I'm not aware of any comprehensive documentation on exactly what optimizations are enabled - in fact I suspect Microsoft would want to be free to enhance their optimizer without notice

Visual Studio publish in debug Vs Release mode

If you publish using Debug mode, your generated files have debugging enabled and that will impact the performance.

It is always recommended that you publish website in Release Mode

Please read this
Don’t run production ASP.NET Applications with debug=”true” enabled

Debug vs. Release performance

Partially true. In debug mode, the compiler emits debug symbols for all variables and compiles the code as is. In release mode, some optimizations are included:

unused variables do not get compiled at all
some loop variables are taken out of the loop by the compiler if they are proven to be invariants
code written under #debug directive is not included, etc.

The rest is up to the JIT.

Full list of optimizations here courtesy of Eric Lippert.

Performance differences between debug and release builds

The C# compiler itself doesn't alter the emitted IL a great deal in the Release build. Notable is that it no longer emits the NOP opcodes that allow you to set a breakpoint on a curly brace. The big one is the optimizer that's built into the JIT compiler. I know it makes the following optimizations:

Method inlining. A method call is replaced by the injecting the code of the method. This is a big one, it makes property accessors essentially free.
CPU register allocation. Local variables and method arguments can stay stored in a CPU register without ever (or less frequently) being stored back to the stack frame. This is a big one, notable for making debugging optimized code so difficult. And giving the volatile keyword a meaning.
Array index checking elimination. An important optimization when working with arrays (all .NET collection classes use an array internally). When the JIT compiler can verify that a loop never indexes an array out of bounds then it will eliminate the index check. Big one.
Loop unrolling. Loops with small bodies are improved by repeating the code up to 4 times in the body and looping less. Reduces the branch cost and improves the processor's super-scalar execution options.
Dead code elimination. A statement like if (false) { /.../ } gets completely eliminated. This can occur due to constant folding and inlining. Other cases is where the JIT compiler can determine that the code has no possible side-effect. This optimization is what makes profiling code so tricky.
Code hoisting. Code inside a loop that is not affected by the loop can be moved out of the loop. The optimizer of a C compiler will spend a lot more time on finding opportunities to hoist. It is however an expensive optimization due to the required data flow analysis and the jitter can't afford the time so only hoists obvious cases. Forcing .NET programmers to write better source code and hoist themselves.
Common sub-expression elimination. x = y + 4; z = y + 4; becomes z = x; Pretty common in statements like dest[ix+1] = src[ix+1]; written for readability without introducing a helper variable. No need to compromise readability.
Constant folding. x = 1 + 2; becomes x = 3; This simple example is caught early by the compiler, but happens at JIT time when other optimizations make this possible.
Copy propagation. x = a; y = x; becomes y = a; This helps the register allocator make better decisions. It is a big deal in the x86 jitter because it has few registers to work with. Having it select the right ones is critical to perf.

These are very important optimizations that can make a great deal of difference when, for example, you profile the Debug build of your app and compare it to the Release build. That only really matters though when the code is on your critical path, the 5 to 10% of the code you write that actually affects the perf of your program. The JIT optimizer isn't smart enough to know up front what is critical, it can only apply the "turn it to eleven" dial for all the code.

The effective result of these optimizations on your program's execution time is often affected by code that runs elsewhere. Reading a file, executing a dbase query, etc. Making the work the JIT optimizer does completely invisible. It doesn't mind though :)

The JIT optimizer is pretty reliable code, mostly because it has been put to the test millions of times. It is extremely rare to have problems in the Release build version of your program. It does happen however. Both the x64 and the x86 jitters have had problems with structs. The x86 jitter has trouble with floating point consistency, producing subtly different results when the intermediates of a floating point calculation are kept in a FPU register at 80-bit precision instead of getting truncated when flushed to memory.

Difference between Debug and Release folders

Just to be clear, the name of the folders in your question are virtually unlimited (not simply limited to debug and release). Right click on your solution and select Configuration Manager and you can add as many configurations as you would like. The name of the configuration is the name of the folder.

As Joshua wrote, usually, people use their debug config to include things like the .pdb file (which includes debugging symbols needed to get line numbers from errors, etc.). Release is normally cleaner. However, you can easily setup folders for x86 vs. x64 vs. any cpu.

If you have a solution with 10 different projects (not uncommon if you work on something of decent size) you might want to build certain projects together and others together. In this case, you should create additional configurations to support this so you can build a group simply by changing your active configuration.

In the end, the folders you mentioned contain whatever you specify in the configuration manager that they should contain.