Compiling for Production: Release vs. Debug

[lmttag]

We have developed a number of different applications (ASP.NET web site,
Windows services, DLLs, Windows forms, etc.) in C# 2.0. We have developed
and unit tested all these applications/components using Debug mode. Now we
are ready to compile everything for release to production. However, we don’t
know whether we should compile all the applications/components/assemblies
using Release mode (or keep everything in Debug mode).

We’ve tried researching Debug mode vs. Release mode but have been unable to
find any concrete information on which one is better, which one should be
used in production and why, if Debug in production is good or bad, etc.

So, we’re posting the question(s) here:

- Should we compile in Release mode for a production release and why?
- Are there any issues releasing Debug mode applications/assemblies into
production?
- What (if any) are the main differences between Release and Debug modes?

Thanks.

 

[Jeroen Mostert]

We have developed a number of different applications (ASP.NET web site,
Windows services, DLLs, Windows forms, etc.) in C# 2.0. We have developed
and unit tested all these applications/components using Debug mode. Now we
are ready to compile everything for release to production. However, we don’t
know whether we should compile all the applications/components/assemblies
using Release mode (or keep everything in Debug mode).

Release. Debug gains you nothing unless you actually plan on debugging the
application in the field, which is rare. What debugging does, mainly, is
turn off most aggressive optimizations (like eliminating local variables,
extracting loop invariants and other things that make your code run faster
but weaken the connection between the binary and the source). It may insert
extra information to allow for edit-and-continue sessions. Some constructs
like P/Invoke and dynamic code generation may deliberately use slower but
more predictable implementations to help you detect problems (this may just
be restricted to when you're actually running the code under a debugger,
though, I'm not certain). None of this helps your customer much, and the
code may run slower.

For managed code, the differences between debug and release code tend to be
less dramatic than for unmanaged code, mainly because it's all JIT-compiled
bytecode anyway. That said, you may experience rare cases where a debug
build doesn't have a problem experienced by a release build (and vice versa)
due to initialization or timing issues. These usually indicate a subtle bug
that's simply doesn't manifest under certain conditions. You should always
perform any tests on the release version as well, as a sanity check.
Nothing's more embarrassing than having to say "but it worked on my machine".

A debug build is ideal for quickly diagnosing and fixing problems, but you
can still debug a release build if necessary, and it's important to be able
to replicate your customer's situation. What you should always do is have
the compiler produce debugging symbols (.PDB) for your application, even in
release mode. In Visual Studio, producing these is controlled by the options
onder project properties -> Build -> Advanced.

These symbols are not for distribution to your customer (unless you don't
mind them seeing your source file names and line numbers...) but they will
help you in debugging an issue on the same binary the customer has, should
this turn out to be necessary.

 

[Göran Andersson]

We have developed a number of different applications (ASP.NET web site,
Windows services, DLLs, Windows forms, etc.) in C# 2.0. We have developed
and unit tested all these applications/components using Debug mode. Now we
are ready to compile everything for release to production. However, we don’t
know whether we should compile all the applications/components/assemblies
using Release mode (or keep everything in Debug mode).

Definitely release mode.

We’ve tried researching Debug mode vs. Release mode but have been unable to
find any concrete information on which one is better, which one should be
used in production and why, if Debug in production is good or bad, etc.

So, we’re posting the question(s) here:

- Should we compile in Release mode for a production release and why?

Yes, because then the compiler compiles the code so that it executes
efficiently, not so that it can be debugged efficiently.

- Are there any issues releasing Debug mode applications/assemblies into
production?
- What (if any) are the main differences between Release and Debug modes?

When you compile in debug mode, the compiler adds extra nop operations
in the code, so that there is always some code for each program line to
use for placing a breakpoint. Also, the generated code is exactly as
written, there is no optimisations such as changing the order of any
instructions or keeping local variables in processor registers.

When the code is executed in debug mode, the garbage collector works
differently. Instead of looking at the usage of variables (as it does in
release mode), it looks at the scope of variables. That means that in
debug mode the garbage collector doesn't collect objects as early as it
could, resulting in less efficient memory management.

Throwing exceptions is MUCH slower in debug mode.

 

[Arne Vajhøj]

We have developed a number of different applications (ASP.NET web site,
Windows services, DLLs, Windows forms, etc.) in C# 2.0. We have developed
and unit tested all these applications/components using Debug mode. Now we
are ready to compile everything for release to production. However, we don’t
know whether we should compile all the applications/components/assemblies
using Release mode (or keep everything in Debug mode).

We’ve tried researching Debug mode vs. Release mode but have been unable to
find any concrete information on which one is better, which one should be
used in production and why, if Debug in production is good or bad, etc.

So, we’re posting the question(s) here:

- Should we compile in Release mode for a production release and why?
- Are there any issues releasing Debug mode applications/assemblies into
production?
- What (if any) are the main differences between Release and Debug modes?

Other has already replied to your questions.

Better that I could have done.

But I just want to note one thing: if you put release versions in
production, then remember to have QA test release versions and
not debug versions !

Arne

 

[Jon Skeet [C# MVP]]

Throwing exceptions is MUCH slower in debug mode.

Well, throwing exceptions is much slower *when there is a debugger
attached*. A very quick test I've just run (basically the code at
http://pobox.com/~skeet/csharp/exceptions.html) performed about the
same with flags "/o+ /debug-" as with "/o- /debug+".

Jon