When to use Release configuration in Visual Studio for SharePoint solutions?

1
votes

I develop SharePoint solutions mainly for SharePoint 2010 with Visual Studio 2010. The regular SharePoint solution development outputs mainly assemblies, which is deployed to GAC and used by other stuff (pages, webparts, controls, etc.). From googling I found that Release configuration includes c# code optimization and doesn't include debug metadata. So I considered that it is useful only on production with high-load parts. And it's acceptable only for stable code - could we connect to release-built assembly on production server with debugger?

So main question is: when to use Debug or Release and which benefits it can give?

1
c#visual-studiosharepointconfiguration

1 Answers

2
votes

Your question is actually not SharePoint specific as there is nothing special about SharePoint and release/debug builds.

The major difference between the two options is - as you suggested - optimization is turned on and debug symbols are not emitted in release mode.

Without these debug symbols you won't be able to debug code on your production site - which you would never want to do anyways, debug something on a Production site, right?!

The Best Practice is the following:

  • Use Debug for all development purposes. If you have a staged deployment (you should), you should deploy the Debug version to your Integration as well as the customer Test environment. This way you can always look for errors on each system.
  • Use Release mode for production purposes. For our staged deployment: Only give your customer assemblies compiled in Release mode.

A note: The speed difference between the "optimized" code and the non-optimized code is most of the time the speed difference is negligible. Most of the time is more of a "you should do this" and not a "if you don't do this, something breaks".