Downside of using Debug builds for production

[Guest]

We are using smartclients in an intranet environment and are considering
using distributing debug builds (.exe, .dll, .pdb, ...). We like the fact
that when an exception occurs we are given a nice stack trace with the line
number of source where the exception occurred. What are the downsides of
using debug builds in production?
Thanks for your help,
Terry

 

[Paul Hadfield]

The biggest downside would be that this indicates there is probably a farily
major flaw in the design of your application, or at the very least in your
exception handling (i.e. none?). With the correct design you can still
obtain (and log) all this information and your program won't fatally fail!
Other than that, i'd guess the only difference could be one of performance,
debug code is probably not going to be as fast or lean as production
compiled code.

 

[Guest]

No design flaw here. Exceptions are being handled correctly. We are making
use of Microsoft's Exception Handling application block. I agree with you
about the performance as a result of the bloated code and additional
assemblies (.pdb's). Releasing debug results in the stack traces that
containing line numbers (production does not) and also allows me to attach to
the process if I desire to debug the application.
Thanks,
Terry

 

[Patrice]

AFAIK debug builds are unoptimized and larger in size.

In my own experience it's not that difficult to find out where it fails even
without line numbers. Make sure to keep your procedures to a minimal size
(good practice anyway). You could also perhaps store some data from your
general layers to help (things like say the name of the last stored proc you
sent to the DB or similar info).

 

[Peter Duniho]

No design flaw here. Exceptions are being handled correctly. We are
making
use of Microsoft's Exception Handling application block. I agree with
you
about the performance as a result of the bloated code and additional
assemblies (.pdb's). Releasing debug results in the stack traces that
containing line numbers (production does not) and also allows me to
attach to
the process if I desire to debug the application.

Others have pointed out some typical differences between a "debug" and
"release" build. Though one must be careful to keep in mind that they are
just generalizations. For example, an "optimized" build could in some
cases be larger than the "non-optimized" build, depending on what the
optimization goals are.

That said, it seems to me that you are really only interested in one
aspect of the "debug" build: the inclusion of symbols (the .pdb file)
allowing for the stack trace to include line numbers in the exceptions.
The ability to attach to the process is a red herring. You can attach the
debugger to any process; the only question is whether you get useful
symbol information when you do so.

While I haven't done this in .NET yet, I would be surprised if it's that
different from non-managed code. In particular, with non-managed code you
can still generate a PDB for an optimized build, and you can still debug
the code using that PDB (as well as do things like use the various debug
helper DLLs to map code addreses to source code line numbers, which is
esssentially the behavior you're looking for with respect to the stack
trace). Of course, because an optimized build often rearranges code,
removes code, etc. there is not always a one-to-one correspondence between
the executing code and your original source code. But that is likely to
be an insignificant issue with respect to the goals you're stating. With
the correct symbols, you can still debug an optimized build even if you
may get disoriented once in awhile, and you can still get reasonably
useful stack trace information.

So, if you are at all concerned about the downside of using a debug build
for your released version (and frankly, you probably should be if your
application is even a little bit performance-bound), it would be better to
go ahead and release an optimized build, but make sure that symbols are
included so that you can get the debugging information you want.

Pete