Deploying app to production using Debug Mode rather than Release Mode?

I work for a shop that maintains a fairly new app. The app still has its fair share of bugs, with numerous tickets coming in daily. The error information we're given with those tickets is not as useful as it might be because the application was compiled in Release mode, which I read is smaller and faster (makes sense).

Are there any ramifications to deploying a .NET application to production that was compiled in Debug mode? I would expect it would be a bit slower, but I've read the difference is nominal. This开发者_Go百科 would assure us that when we get errors on tickets we have line number associated with those errors and this, of course, makes debugging much easier.

Any major red flags that would prevent you from doing this? I'm tasked with researching the possibility. So thanks for any feedback.

Deploying your app in DEBUG instead of Release mode will slow down your performance. Of course compromises can be made. I would suggest one of the following:

• Look at adding a global error handler to the OnError in your global.asax-
• Look at a compromise similar to this one suggest by Scott Hanselman

My experience is that this can work okay if you're thinking about a desktop (winforms/WPF) app, but under no circumstances should you try this with an asp.net app.

You tagged this [vb.net], you cannot ship debug builds or programs that use WithEvents. There's a known and afaik unsolved memory leak for WeakReference instances if there is no debugger attached. They are used to support Edit+Continue.

First thing you can do is ship the .pdb files along with your apps. In the C# IDE use Project + Properties, Build tab, Advanced, change Debug Info to "Full". You'll get line number info in the exception stack trace.

You cannot completely trust the line number, the JIT optimizer will move code around to make it execute faster. And inline short functions like property getters. You can add an yourapp.ini file in the same directory as the executable that disables the JIT optimizer

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

It all depends on significance of your production environment, business and performance requirement. Nothing is strict.

Deploying Debug builds is a red flag to me though it is not unheard of. Is this a desktop or server app? Any calls to Debug.Assert that fail could be an issue as those can shut down your app and/or cause a debugger to attach (VS.NET is not the only debugger and if I recall .net fx installs a lightweight debugger). While that can be helpful as a dev it certainly can be confusing to a normal person.

One option that works well is rather than debug builds ensure that your error reporting mechanism includes (either displays or logs) the stack trace information from any thrown exceptions. This help pinpoint bugs very nicely wihtout needing pdbs.

If this is a desktop app, you could try it with a few customers, but heed the advice given in other answers. Try someone who is more of a power-user or having a lot of issues may be willing to volunteer.