Set configuration to release or leave as debug

In Visual S开发者_Go百科tudio, when you compile your code to install it in production environment do you change the configuration to "release"? If you do, have you found some performance improvement or you do because some other factor? Can you share this factor?

Release mode code goes thru compiler optimizations, all debug symbols are removed, project state info is discarded and a lot more to run it as efficiently and lightly possible. t is always a good idea to publish the Release mode version of your library to production.

However, there is a trick to get best of both worlds: http://www.hanselman.com/blog/PermaLink.aspx?guid=a40c0d4f-66d0-4704-94f6-0efda4a44465

Change it to Release for what you deploy. Release target switches on optimization. All other factors equal your code is faster. The degree of improvement depends on your code.

Release also switches off the DEBUG and the TRACE constants. Both may execute additional code or even create file access (writing logs) that you typically don't want in a production environment.

When you have the configuration set to Debug, there is a lot of extra information generated by the compiler in order to allow you to step through your code in visual studio. If you are making a library, or anything really, and you want it to be production, you don't want to release the debug version. Its going to be bloated. Also, if it wont handle crashes as elegantly (not that you should have any in the first place :P).

Specifically, the compiler will not optimize things as well as it normally could since it needs certain information to give back to the debugger. The release version will certainly run faster, but its not always a noticeable increase in performance.

You would usually use Release configuration. Debug version are usually larger files, sometimes much larger; they usually use more memory than release configurations (as they pad variables/globals for debugging memory management etc), and also perform differently to release in that they initialise uninitialised variables to specific values (usually all \0, but that's definable per project I think).

As they also contain debug info, it could allow the end user to much more easily reverse engineer an executable/library, which you probably don't want them to be able to do.

The production environment would most likely also need the debug libraries installed, which adds to the re-distributable files you'd have to package with your app.

We have our build server set up to do release builds for QA (and we ship what we test).

As I understand it, assemblies produced in release mode are:

• faster
• smaller
• do not contain debug information.

For more detailed information, have a look at these:

• Debug Visual Studio Release in .NET
• Beware of deploying debug code in production