If the release version produces .pdb files and you can step into every line, put breakpoints etc then why ever bother to build a "debug" version of my components?
I'm using c# for my projects and i didn't have problem debugging release versions. In C++ i had problems debugging optimized code but in C# it works fine. I'm not talking about silly code blocks like if(false)...
On
There are a few reasons:
Debug.Assert etc will be removed.A lot of this can be changed in the build configuration, of course. One fairly common approach is to leave the default settings alone except for including more debugging information in a release build, which can give you more useful stack traces (and allow a better debugging experience if you do use the debugger).
On
Apart from the other answers, I use the automatically generated #define DEBUG to change behaviour when an uncaught Exception occurs:
On
I agree with Lennaert - I tend to do different error handling between the builds. For example, for some of the apps I am super anal in the debug build. Pre- and post-conditions, assertions, exceptions, etc. I basically am trying to force the developer to use my library correctly. In the release build, on the other hand, I relax the conditions to improve performance.
On
When you use Design by Contract, it is important to have two builds - the release one which doesn't check Preconditions, Postconditions and Class Invariants and the debug one which checks them (via assertions).
In some situations, Precondition checks may be left active in release mode (search for related questions), but that doesn't change the whole story.
In the development phase you check all of your contract assumptions, and when you release, you don't check them anymore - you know you have tested the code and it works, so you just rely on your previous assumptions - that's why they were intended for in the first place.
On
The release builds are more optimized, e.g. when I debug release builds it annoys me that local variable's values disappear when their values are not going to be used by the runtime.
On
Release builds perform additional optimizations than debug builds, however a debug build also slightly changes the behavior of the GC to ensure that you don't get an object collected out from under you while you are in the middle of a debug session. Debug builds also prevent certain optimizations from occuring during JIT which will have a negative impact on your debug session.
One reason is attach vs. launch.
If you launch a Retail process in .Net, the debugging is almost nearly as good as launching a Debug process. You will likely not notice any difference in your debugging experience.
Attach is a completely different ball game. Both C# and VB are passed the /optimize+ flag for retail builds. This will embed the DebuggableAttribute at the assembly level without the DebuggingMode.DisableOptimizations flag. During a process launch, VS / CLR, will communicate to essentially ignore this fact and disable JIT optimizationss that impact debugging. During attach, no such item happens and the JIT/CLR will optimize to it's hearts content. I guarantee you, the debugging experience is much worse in this case.
You can experiment with this in VS