How should I use debug/release mode in Visual Studio?

Question

I usually test my code locally on my work machine and then move it to development environment and then finally to production environment. What is the best way to use debug/release mode for this scenario? Do I only need to care about debug mode in my machine? Should I publish debug mode or release mode to development? I know probably I should publish using the release mode to production. I didn't really pay attention to all of this before so I have been working only in debug mode all the time, which I know I shouldn't.

Edit: Thanks for the answers. It looks like it's a good idea to only use debug mode in my own machine. Even though it's in development machine, it's basically releasing to the public (co-workers, qa) so it should be in release mode. And of course it should be release mode when releasing to prod.

Answer 1

When releasing / publishing an application you should do so in Release mode. Release mode is for just that, releasing applications. The code produced is typically more performant and many removes many checks that are more associated with the development phase of an application.

In a typical day, you should be developing in Debug mode. Most languages insert extra checks into a debug mode application. These spot more bugs but tend to slow down the application a bit.

Yet you must also do siginificant testing of Release mode as part of your development process. Customers will only actually see the Release mode version of your product and it's possible for bugs to be Debug / Release mode specific. The bug checks inserted in debug mode can introduce side effects that hide real bugs in your application.

Answer 2

In general, ALWAYS deploy Release builds to production. Debug will add to your assembly weight and degrade performance.

If you are developing ASP.NET applications, leaving Debug mode on actually changes how/when your pages are compiled by the JIT compiler and significantly degrades performance to add better interactive debugging ability.

As far as which build to deploy to development...if you are running unit tests against development, it is probably a good idea to deploy the Debug build so you can get the most debugging information when tests fail or exceptions occur. However, there is hopefully an additional Testing or Pre-Production environment where you can have your integration tests running and manual tests are performed there. That Testing/Pre-Prod environment should DEFINITELY be using Release builds so that you can see the true perfomance and compilation issues before going to Production.

If you don't have this intermediate Testing/Pre-Prod level, then I would suggest running your Dev environment with Release. In other words, you should run at least one level before production in Release configuration.

For more information on what you can do with configurations, I have a blog post specifically for Silverlight (http://blog.tonyheupel.com/2009/04/environment-specific-service-references.html). In there is a link to Scott Hanselman's more generic article on build configurations and different environments.

Answer 3

By default, the release build will be compiled with more optimizer switches on, which will result in faster and smaller code, which is typically what you want to release to customers (hence the name). T

he debug build does almost no optimizations, which means that when using the debugger, the underlying machine code corresponds more closely to the source code, which assists with debugging. Also, the debug build by default inserts extra runtime code checks which will catch common errors like accessing uninitalized array members.

Note that you can build release builds with debugging symbols, it just becomes harder for the debugger to map the current statement in the machine code to the appropriate line of source.

Answer 4

I follow this approach:

• code/debug cycle on my workstation: DEBUG
• running unit tests on my workstation: DEBUG
• profiling on my workstation: RELEASE
• overnight build and automated tests: RELEASE (performs an unattended install)
• hands-on testing by QA team: RELEASE

All testing must be carried out at least on the release build, because it's what you're going to ship. Profiling on the debug build is usually pretty pointless (especially in C++) because debug heaps have a lot of extra checking that totally changes the performance profile of a typical application.