Implications of deploying a Debug build of an application?

views:

answers:

+3 Q:

Implications of deploying a Debug build of an application?

I would like to know the pros and cons for deciding to deploy an application which was built in Debug (with debug symbol table) and opposed to Release mode where the symbols are stripped. There are other permutations like turn on optimisations for Debug and turning on debug symbols for Release.

The areas which I think may be of concern are (you might know others):

Security
Performance
Stability

But I am not an expert, so I am not sure of all the implications for which deploying a Debug application will have on these areas.

It might not be relevant, but this application is a C# .Net framework 3.5 (business app that manages terrabytes of data) for those concerned. This is an application for a (paying) client.

Are there any clear advantages or disadvantages in choosing to do this?

+1 A:

You could also give them a release build with debug information.

Steven Sudit 2010-09-15 02:18:59

I know I can do this. Could expand a bit more on reasons to or not to do this

Brock Woolf 2010-09-15 02:21:26

The code runs optimized, so you don't introduce performance issues. But you still get some of the benefits, such as more detailed stack traces.

Steven Sudit 2010-09-15 02:24:23

@Steven Sudit: Okay, but talk about it in your answer.

Brock Woolf 2010-09-15 02:27:29

Nah, it's clear enough this way and I'm fine with GenEric35 getting the Accepted nod.

Steven Sudit 2010-09-15 13:17:28

+3 A:

Security: Debug and release managed code like C# is already vulnerable if not obfuscated. Protect your code with obfuscation, otherwise it can easily be copied, stolen, any security like encryption cracked(you mentionned in this case Terrabytes of data for a customer). I have answered a obfuscation question here. Also, make a key file and sign your assemblies.

Performance: Debug is definetly slower, should never release a debug build. If using AJAX would make each page request much heavier since the debug version is bigger. Set the debug flag to false your application config file, i have included a few similar reminder in this other question.

Stability: Debug uses more memory, and could be less stable if server has low memory. An advantage of having debug dlls is if the application fails, your pdb files would already be in place. The best practice is to keep the debug build somewhere safe for every release version you build. If a customer requires you to debug, backup his folder and replace it with your corresponding debug assemblies.

I have developped on an archiving product that also archived Terrabytes of data, and I would NOT recommend to deploy a debug build and would make sure it's obfucated, and file encryption methods encrypted with Dotfuscator.

GenEric35 2010-09-15 02:26:08

+1 With Reflector etc, if it's not obfuscated, whether it is Debug or Release is largely irrelevant. Just like with System.Reflection, "private" is just a suggestion.

Jim Leonardo 2010-09-15 02:35:52

I like your idea for building both Debug and Release and then replacing when necessary +1

Brock Woolf 2010-09-15 02:45:49

Debug isn't just slower, it's... different. If your code depends on optimizations, it'll just plain break. A good example of this (and not recommended!) would be checking the call stack and expecting the caller not to have been inlined.

Steven Sudit 2010-09-15 13:17:06

+1 A:

Hopefully, this blog from scottgu answers your questions!

http://weblogs.asp.net/scottgu/archive/2006/04/11/442448.aspx

This is for ASP.NET applications tho. Most of them are true for other project types as well.

Josh 2010-09-15 07:06:50

ansaurus

tags:

views:

answers:

Implications of deploying a Debug build of an application?

related questions