.net debugging on production server [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 3 years ago.

Improve this question

My team and I are working on a .net web app project for the first time. We want to know the most effective way to debug issues on a production server. Currently, we ftp upload our work to a client's production server.

Since our background is in LAMP, we're using to SSHing into the production server, and using a combination of die(), print_r() and comment out techniques to troubleshoot the problem.

Unless I misunderstand the way .net work, I don't think i can use the same approach because changes to .net开发者_JAVA技巧 code behind requires a complete re-build of the project (on localhost), then an upload. This is too time consuming....

Is there a better way to troubleshoot issues on a production server?

---

When dealing with production issues, its best to have an environment that replicates production. In that environment you can deploy the same app, but with debug enabled. This would allow for you to have a whole suite of tools you dont want available in production.

Once armed with this environment, all you need is to find out where the exception is happening (through logging/tracing) and how to reproduce the problem.

The issue is production environments are design to be fast (no debugging, minimal logging) and secure. So admins hate things like debugging or even the concept of remote debugging.

The goal of well designed architecture/production software, is to collect enough information about what went wrong, so you can reproduce the error/scenario in another environment.

---

There are really only three ways to debug server side issues.

Logging Plan ahead and add logging to your application. Most logging frameworks like log4net and Enterprise library have modes to log more or less information depending on a configuration setting. IIS also has its own logging that you can look at.

Instrumentation You can add performance counters to your application and also use the existing performance counters if you are having a performance issue. Also tools available from Sysinternals and WireShark can come in handy for problems outside of your code.

Memory Dumps You can capture memory dumps of your application and use a tool like WinDbg to look at a snapshot of what's going on in your system.

---

There are a variety of different logging frameworks for you to choose from that you can change the settings without the need of a rebuild. You can set the logging level within a config file, Eg. Error, Warning, Debug, etc...

You include instrumentation code for all logging levels in your application and those log statements will only execute if the log level is set.

Here is an example of one such offering.

http://msdn.microsoft.com/en-us/library/ff647183.aspx

---

The stack traces provided in .NET, once you learn to understand them, provide often enough value to really track down an error. You can enable remote debugging but since it's a client's machine and it's a real pain in the butt, I would avoid that.

Mostly you make sure you have test coverage, understand how to read exceptions, and take some time thinking about exceptions you see. In 10 years of .NET work I have only wanted to debug on a production server once and I ended up finding out the bug without that.

Also, you can use ELMAH to capture unhandled exceptions, which is helpful.

---

Debugging should happen at development phase with "debug" option enabled. When you deploy to Production turn off "debug" option for efficiency. In production, however you can log the error/exceptions/stack traces etc in a log file which will help you to troubleshoot the issue at hand.

Again, those die(), print_r() are perl debugging way since perl don't have any built in exception OR error tracing mechanism. That way it don't work in case of .NET.