Notes on Debug mode versus Release Mode


Dlls compiled in debug mode should stay in the developmental environment while they're being debugged, improved, stepped-through, and tweaked.

When the dll is ready to be deployed (released) to a high-traffic server—such as a SharePoint TEST, QA, or Production Farm—the dll should be recompiled in release mode.

When in debug mode. . .

  1. Expect the memory footprint of the process to be enlarged since debug symbols are required to be loaded.
  2. Expect a substantial performance hit due to the debug and trace statements (System.Diagnostics.DebuggableAttribute) in the output IL code. In debug mode there are several extra instructions added to enable you to set a breakpoint on every source code line a debugger such as Visual Studio.
  3. Also the code will not be optimized by the compiler. JIT optimizations will be disabled. (IsJitOptimizerEnabled)

In release mode. . .

  1. all calls to Debug class methods in your code are disabled.
  2. Code is optimized during the build operation
  3. You cannot take advantage of any source-code level debugging tools. You cannot set breakpoints.
  4. Better performance
  5. Smaller memory footprint






Comments (5)
  1. Lucian Bargaoanu says:

    Actually you can use breakpoints in Release. And you should have debug symbols for Release too.

  2. Matt Ridgway says:

    @Lucian – symbols can be generated in release for debugging, but why would you want them to be? By that point your code should be tested (code/integration/regression) and any logging you require to trace bugs should be done separately. Past a staging environment you shouldn't be debugging production code, depending on your project (for example MVC – using a remote debugger and putting break points in controllers)  you could be affecting all traffic to your site, not just your requests. On large deployed systems this would be a big no (can't see Facebook doing that). If your needing to debug live code its probably highlighting mistakes in the rest of your release process.

  3. Dzejms says:

    You put symbols in production on release builds so you get better stack traces in error logs with line numbers.  Some tools like Application Insights will gather state and persist that for you in their exception reports so you know the values of the variables when something went wrong.  

  4. Anton says:

    Totally agree with @Dzejms and @Lucian, production symbols may save your life, especially if you have to dump your process for examination inside WinDbg.

  5. Great discussion.  Thanks for the comments!

Comments are closed.

Skip to main content