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?

2 Answers
2

No, you can't connect Visual Studio to Release configuration code. The code is optimised and does not contain debug symbols, so you can't attach a debugger.

You can reconfigure the Release build to include debug symbols (and this doesn't really reduce performance), but the code is still optimised, so what it's running does not necessarily match what you see in Studio. It's quite funny - when I tried this the yellow 'current' line started highlighting spurious lines. It's not much good, so this configuration would make little sense.

However, the optimisation does make it faster. Those are pretty much the advantages and disadvantages.

So the short answer is what you've said already. Use Debug during development, but Release when releasing stable code. Note that stable code probably should still have minor things like Logging built in.

Basically you should use Release when you are building for your production environment. You can debug release code when attaching the debugger in Visual Studio. Debug builds are a bit more optimized specifically for debugging, but you can still step through release build code.

There are also some questions over on Stack Overflow that shed some additional details that you might be looking for: