Can I change the EventLevel attribute at run-time in my EventSource?

Topics: Semantic Logging Application Block
Mar 16, 2013 at 3:18 PM
Edited Mar 16, 2013 at 3:32 PM
I know that EventLevel can be changed by modifying the SemanticLogging-svc.xml file for a given EventSource.

What I want to try out is this:
-10 web apps use my CustomAppEventSource : EventSource
-These web apps call CustomAppEventSource.WriteInformationalMessage(string appName, string message)
-At runtime, I want WriteInformationalMessage to change it's EventLevel.Informational to EventLevel.LogAlways -- but based on the passed in appName

(warning: i know passing in the appName is not a good design, but bear with me in this example)

[Event(200, Message = "Generic Informational Message", Level = EventLevel.Informational)]
internal void WriteInformationalMessage(string appName, string message)
    -EventLevel newLevel = GetAppDetailsFromConfig(appName).EventLevel       
    -Use PropertyDescriptor/CategoryAttribute/FieldInfo to set the "Level" attribute to newLevel       
    -WriteEvent(200, message);
I'm considering using one CustomAppEventSource for lots of applications (10+) residing on my environment, because I'd rather have 30+ developers use one CustomAppEventSource that writes to one database table instead of setting up a new EventSource for each application.

This means that I'm also trying to write a Custom DatabaseEventListener that adds an "ApplicationName" column so that 30+ developers and customers can query this one table based on their application. It also means that I may want to turn on Verbose logging for just one application in Production (to troubleshoot an issue), and not all applications.

Why am I considering this? Because for many years, all of our developers have been using an internal shared library such as "Company.SharedLibrary.EventLog.WriteEvent()" to write errors to EventVwr. This shared library has done the job of parsing out the namespace of the webapp, and creating a new Windows event log for brand new apps, on the server, for them. Since eventvwr sucks, is slow (ever try doing 'eventvwr \\server' especially when some developers are on the other side of the world?), hard to query, and only contains errors, I would like to evolve our approach to logging into all areas such as: Errors, Tracing/Informational, Performance, Auditing. But at the same time, retain our approach to using one common EventLog library (aka EventSource). On the same note, many new applications are using Elmah or a custom logging approach, and this is starting to get messy and harder to maintain -- hence the push towards every app using a central solution.
Mar 19, 2013 at 3:39 AM
I totally understand where you are coming from (and I feel your pain with the eventvwr!).

With that said, I think the approach is not really embracing the spirit of semantic logging.

From a technical perspective, I don't think you will be able to change the level at runtime since the EventAttribute (including the Level) is read at runtime to generate the manifest.

One approach would be to create a logging facade (perhaps similar to ILog. Internally the call could be directed to the appropriate EventSource method (if the logging level was enabled for the specific application).

Randy Levy
Enterprise Library support engineer
Support How-to
May 14, 2013 at 5:10 PM
Hi Jonny,

I just read this post (I know it might be a bit late) but an alternative option using plain EventSource would be exposing a method decorated with [NonEvent] so it will not be included as part of the manifest and inside that method just call the appropriate event according to your configuration.
On the other hand, perhaps the best way to use levels in you EventSource would be applying the filtering when you enable your listener with;
[listener instance].EnableEvents([your EventSource], [your level from config])