Saturday, 13 September 2008

Logging (not the tree kind)

Logging is a great tool when it has been implemented and things go wrong in production. ASP.NET applications can be a real bother when there is no logging of any sort.

I am a bit of a late starter when it comes to implementing logging within my applications and the only options I really had was writing either to the Event Log or writing to a database "Audit" table. Both options tend to involve writing a pile of code that I was never really all that happy about.

Then for a long while I kept hearing about a wondrous tool to solve all my logging woes... Log4Net

Log4Net just made logging so easy. I'd wrap Log4Net into my own custom class which would give me the basic methods to call appropriate Debug/Warning/Error/etc. methods and I would be away laughing.

Configuration was reasonably straight-forward. Log4Net gave me the flexibility to log "fatal" errors to the Event Log and/or email them to the appropriate person. All other levels of logging could be switched off and on at will and would log to a daily file.

All as sweet.

Then one day not too long ago I was watching a screen-cast from a certain fellow called Rob Conery. He just happened to brush upon the notion of logging within this particular installment of his MVC Storefront series but he wasn't using Log4Net!

Shock! Gasp!

*** NEWS FLASH ***

I seem to have killed Rob Conery's web site! Saturday 13th at 6:05PM NZ time... It may just be a coincidence. Or maybe it is just playing up for me. All I was doing was clicking on a tag in the tag cloud and it stopped working.

My bad.
*** NEWS FLASH ***

Anyhoo, back to the gasping...

He implemented not Log4Net but a relatively new kid on the blog... NLog

Dramatic riff...

I love it.

Just as simple to use as Log4Net and even easier to configure. More importantly easy to extend! The first thing I did was write my own custom layout renderer.

The documentation is quite straight-forward but I did have one stumbling block when I first tried to view all my wonderful new logging files NLog was now creating. Except it wasn't and it nearly put me off NLog because I couldn't see why.

Of course the problem boiled down to an assumption I'd made with the configuration that carried over from Log4Net.

When writing to a file I assumed it would be relative to the folder where my application was running and so I specified a relative path for the log file NLog was to write to.

Thanks to ProcMon from SysInternals I saw the error of my ways and then defined absolute paths for NLog. Of course, don't forget to make sure the account the worker process is running under has permissions to write to the location of your log files.

So like magic my application was now happily logging messages into the folder I designated for it.

And now I am happy and plan to use NLog in all my future applications.

Until something new takes my fancy of course...

NOTE: I am not sure how long Rob Conery's site was down for but was back up again 25 minutes later when I checked again.

2 comments:

  1. Down! Hmmmm... what kind of error was it? 404? YSOD? Glad you like NLog - they are both very similar, I just found NLog to be a bit lighter weight :).

    ReplyDelete
  2. Worse than that... I just got back nothing. No 404 error or the like and no YSOD.

    Just a blank screen with no data.

    Most likely is was just me. A network error perhaps. My system does get a bit funny at times, but when it does my whole network goes on the fritz, not just one site.

    ReplyDelete