Thinking of an ideal logging framework

First, let me say that logging is important. It's one of the Martian Principles:  #13 Log Everything. Disk space is so cheap anymore that having weeks worth of detailed logs shouldn't be any big deal, provided you aren't taking a noticeable performance hit.

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:

1. 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.
2. 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. 

Hand editing config files on a live and running site seems like a bad idea to me. One wrong save and BANG site is offline or not working correctly -- silently broken. And if what you silently broke is your logging? Ouch. I'd prefer to have Production locked down to the point that this just isn't an option unless it's an emergency.

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.