Start Debugging vs. Start Without Debugging

Keyboard:  F5; CTRL + F5
Menu:  Debug -> Start Debugging; Debug -> Start Without Debugging
Command:  Debug.Start; Debug.StartWithoutDebugging
Versions:  2008,2010
Published:  11/1/2010
Code:  vstipDebug0037

While researching this one I came across a LOT of misinformation concerning what is actually happening here.  There seems to be a great deal of confusion as to what is actually happening when you use Start Debugging (F5) versus Start Without Debugging (CTRL + F5):

Starting With Debugging

Let's start with the basics:  When you press F5 (Start Debugging) in Visual Studio it launches your application, attaches the Debugger, and let's you do all the "normal" things you would expect: 

According to the documentation (https://msdn.microsoft.com/en-us/library/k0k771bt(v=VS.100).aspx) here is what the Debugger does:

"The Visual Studio debugger is a powerful tool that allows you to observe the run-time behavior of your program and locate logic errors. The debugger works with all Visual Studio programming languages and their associated libraries. With the debugger, you can break, or suspend, execution of your program to examine your code, evaluate and edit variables in your program, view registers, see the instructions created from your source code, and view the memory space used by your application."

The Debugger:   Release Builds

One popular misconception is the Debugger doesn't come into play for Release builds.  This isn't true.  Set a Breakpoint in some code for a Release build and then press F5 to see if is stops there:

Of course it does!  The Debugger is attached!  That is what is happening.  Now, there are some things that aren't happening as well.  For example, you can't use the System.Diagnostics.Debug class methods to send messages to the Output window since the compiler strips them out for Release builds:

Start Without Debugging

This is exactly what it sounds like.  It starts the application WITHOUT THE DEBUGGER ATTACHED.  That's it!  Nothing else.  It just doesn't attach the Debugger.  Otherwise everything else is the same.  So, the practical implications of this are obvious:  Without the Debugger attached when the application runs it will not hit Breakpoints, emit Debug messages, etc.  So now let's deal with the biggest myth about Start Without Debugging.

Myth: Start Without Debugging Creates a Release Build

Nope.  It uses the build you are currently on.  So if you are using a Debug build and you press CTRL + F5 then it will run that Debug build.  The easiest way to test this is to use conditional compilation to see if you are using a Debug build:

In this example, the Console statement will run but the Debug statement will NOT run because the Debugger is not attached.  So I will get this output:

And, if I attach the debugger after pressing CTRL + F5, to this process:

Then this is what I get:

The Debug messages haven't been stripped out because I'm using a Debug build of the application.

Finally

Okay, so the obvious question is "Why?".  I mean, why would they give us this option?  Well the most obvious answer is so we can run the application without having to hassle with disabling breakpoints, etc. to do a quick "Smoke Test" and see if it runs.  There may be other reasons you have for wanting to run without the Debugger attached as well.  So now you have a better idea of the difference between Start With and Start Without Debugging.  Go forth and debug away!