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!
My bad.
Anyhoo, back to the gasping...
He implemented not Log4Net but a relatively new kid on the blog... NLog
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.