By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,458 Members | 1,463 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,458 IT Pros & Developers. It's quick & easy.

Compiling for Production: Release vs. Debug

P: n/a
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.

Jul 14 '08 #1
Share this Question
Share on Google+
3 Replies


P: n/a
lmttag wrote:
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.

--
J.
Jul 14 '08 #2

P: n/a
lmttag wrote:
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
Jul 15 '08 #3

P: n/a
On Jul 15, 12:55*am, Gran Andersson <gu...@guffa.comwrote:

<snip>
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
Jul 15 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.