Reading this question, in the first comment, @Cody Gray says:
Erm, you know that you’re not supposed
to redistribute the “Debug” version,
right?
I’m concerned about it. In Visual Studio, I usually develop my applications in Debug mode, and if I need to distribute the executable, all I do is zip the .exe and required .dll files (in bin\Debug folder).
Why is it a bad idea?
What is the difference between doing this and doing exactly the equivalent thing in Release mode?
Edit:
I asked this question time ago, but I just wanted to edit it to add a difference:
When using Debug.Assert in the code to test it, and compile in Release Mode, all those lines are gone, so that could be another difference.
It depends on what kind of language you use to develop your program. When you use C++, you get the overhead of /RTC and the Edit + Continue support. They slow down the generated code by a great deal and make it likely your app crashes early on a StackOverflow if you use recursion. The runtime exceptions you can get from the checking code can be hard to diagnose without a debugger.
If you use VB.NET then you’ll easily have a unpluggable memory leak when you use the Debug build without a debugger. A flaw in its Edit + Continue support code causes a WeakReference to be leaked for every instance of a class that contains a WithEvents event. Your app eventually dies on an OutOfMemory exception.
If you use C# then not a heckofalot goes wrong, the JIT compiler is just prevented from generating optimized machine code and garbage collection isn’t as efficient. Your program will run slow and consume more memory than necessary. This applies to VB.NET and C++/CLI as well.
Perf is usually foremost on a programmer’s mind when writing code. As such, shipping the debug build is a bit blasphemous. A significant number of programs are however completely throttled by I/O, the disk, network card or the dbase server typically. Raw cpu perf doesn’t matter a great deal in that case.