Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

Debugging and Tracing

Am I the only paranoid .NET dev who is constantly thinking of the best ways to put debugging and tracing in his application? I see (in the very little time spent looking at the forum) no worthy mention of thoughts on that topic. So maybe it's not a big question and maybe everyone just knows everything there is to know about debugging/tracing... Don't know.

The part I like is being able to turn on via configuration, tracing  on a machine where the app is deployed.

Any of you intelligent ones out there have valuable thoughts on this topic? Thoughts such as, how much do you use in your apps? Function level is sufficient? How much do you dump on a Level4 trace? Sometimes I discuss this stuff just to get someone else's perspective. Most of the times, that pays off big time! :-)

Sheeshers ( http://spaces.msn.com/members/ashishs )
Sunday, January 30, 2005

It's invaluable to me. We wrote a custom tracer that can look at a config file and log events to various handlers based on the log level. For example, right now all debug statements are being written to a log file (archived nightly) and a SQL table, Warnings are emailed to me, and Errors and Criticals are emailed to our main support address.

It's great to be able to look back and see exactly what steps a customer performed to trigger an error.

And because it is all configured as settings in our main config file, turning it on, off, or increasing the tracing is fairly straightforward.

As for what gets traced, pretty much anything that I could ever want to know. User inputs, object definitions as they move through methods, database calls, ip addresses, user information. I should be able to look at a debug file and see exactly what happened as the user moved through the application without having to use a debugger to step into method calls.

Cory Foy (cornetdesign.com)
Monday, January 31, 2005

I thought of the idea of the warnings and errors being emailed too. But how much overhead does that create when you're deployed to hundreds of customer machines like we are? Or maybe you turn it off at that point and only use it in your lab when going through QA testing.

Will pursue that idea and research some good ideas on implementing that gracefully and easily.

Sheeshers http://spaces.msn.com/members/ashishs
Monday, January 31, 2005

I think there are two choices in this space.

First, for simpler logging needs, use log4net.

http://logging.apache.org/log4net/

Second, for more complex needs, examine the recently released Enterprise Library.

http://weblogs.asp.net/scottdensmore/archive/2005/01/28/362811.aspx

Brad Wilson
Tuesday, February 01, 2005

I love log4net. Currently I get everything users do logged to a text file (which can be searched if anything goes wrong). Errors are currently emailed direct to me, as are warnings whilst I'm in beta phase.

I even wrote a tutorial on setting it up, because the one on the site seemed pretty useless: http://tinyurl.com/6v4cx

Colm
Wednesday, February 02, 2005

Although I haven't tried using Log4Net yet, the primer on Colm's website made it far more easy for me to understand how I should use this thing.

So if first-time users are looking for a good intro besides the documentation that comes along with the app, I'd recommend the link in his post above.

Sheeshers
Wednesday, February 02, 2005

The only way I've been able to get trace logging to work in a .NET web service is to log to a database table.  Any time I tried to log to the filesystem I would get errors along the lines of "another process has the file open" after a couple of hits on the service.

I take that back I was also able to use the Windows event log but found that the setup work was ridiculously complicated subsequent review of the log was painful.

wishing windoze had syslogd
Friday, February 04, 2005

I have used log4net extensively taking advantage of many of its loggers.  However by far the most useful appender for me has been the OutputDebugStringAppender as I can view all the output using DebugView from <a href="http://www.sysinternals.com">www.sysinternals.com</a>
This works out best for server apps as DebugView has the capability to connect remotely (as long as you have admin rights to the machine you're attempting to connect to).
This is just as good if not better than syslogd, which the previous poster was refering to.
Another great feature of log4net that comes in very handy for server apps is using the Nested Diagnostic Context to easier identify each specific request, I usually push the user name on the NDC.

Abstract Structures
Wednesday, March 02, 2005

*  Recent Topics

*  Fog Creek Home