Why is a bad practice to distribute the Debug version of the application in .NET?

Question

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.

Answer 1

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.

Answer 2

I think performance is an issue, this post has more detail

Answer 3

A pure C# or VB.NET application may work on any machine with the right .NET framework redist being installed, but a C++ or C++/CLI application (or a mixed application) needs the VC redist package, which does not contain the debug versions of the needed libraries. Assuming that on your users PC Visual Studio is not installed, only a redistributable package, I would say you have the risk that a debug version of your program simply might not work there.

Answer 4

There are legal reasons also - Quote: "Note that debug versions of an application are not redistributable and that none of the debug versions of various Visual C++ dynamic-link libraries (DLLs) are redistributable." From Redistributing Microsoft Visual C++ 6.0 Applications

And this is for Visual Studio 2010 "Determining Which DLLs to Redistribute": "You cannot redistribute all of the files that are included in Visual Studio; you are only permitted to redistribute the files that are specified in Redist.txt. Debug versions of applications and the various Visual C++ DLLs are not redistributable. From Determining Which DLLs to Redistribute

Answer 5

Regarding performance, I'd be interested to see some metrics about debug versus release.

Whilst I'm sure the metrics would vary depending on exactly what the application does, but my hunch is that most of the time the end user wouldn't know the difference.