Re: Compiling for Production: Release vs. Debug
- From: Jeroen Mostert <jmostert@xxxxxxxxx>
- Date: Mon, 14 Jul 2008 21:41:27 +0200
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.
.
- Prev by Date: Re: Forcing Generic Types....
- Next by Date: Re: How can I select only the parent node of a treeview treenode?
- Previous by thread: Forcing Generic Types....
- Next by thread: Re: Compiling for Production: Release vs. Debug
- Index(es):
Relevant Pages
|
