Today I'm working with the Enterprise Library Logging framework and finding it lacking. It certainly does all-that-and-a-bag-of-chips. But it's got some issues that have really tedious workarounds:
- Changing logging configuration on the fly without restarting your web app isn't easy. You have to add some custom code to make Enterprise Library look for a config file that isn't web.config. Small workaround, but every app needs it. I hear that EL 5.0 Optional Update 1 has a fix for this. Note the version number there: EL is up to version 5 and just now it's thinking of a standalone config.
- Changing the EL.config as part of your deployment is wow a lot of work. I found this post by Oleg Sych that explains how to do it. It isn't trivial. Getting the rest of my team to agree to that amount of work to get Prod/Testing/Debug configuration of EL.config working? Hah, forget it. It requires hand-editing of the csproj file. Not good.
I did look at ELMAH. It looks good, but it breaks the MP#13 because it's only logging the errors.
So, the ideal laundry list for a logging solution:
- Simple simple simple to add to an existing app.
- Configure the logging level on the fly without restarting the app.
- Write to a local (in the app directory) no-footprint database.
- Multiple handling of certain classes of entries (errors get an email, verbose entries don't)
- Easy to configure for production deploy via a script or .config transform (preferably second option)
We had a similar setup at the last job (but it wrote to the Windows event log, yech). I don't really want to roll my own here. We were using log4net, but I recall a lot of configuration pain around it. Not sure why, but the guy who was working on it was bright enough that I don't think he was the issue. Plus, I think the on-the-fly config was something we had to do on our own.
Will update if I can find anything that satisfies all these conditions.