Apr 30, 2009 at 9:34 PM
Edited Apr 30, 2009 at 9:47 PM
When I log to the windows event log directly through the BCL, I can directly specify the "Log Source" to be used (as well as the category):
//This is the "Log Source"
"BCL event message",
2 //A category enumeration representing "Performance"
The above arrangement allows me to write plugins that rely on ComponentInstaller instances to create "Log Source" entries that are unique for the plugins. In short, a plugin called "Omega" can write a log entry to the
"Omega" Log Source, using the "Performance" category (enum value '2' in the example above).
But when I use the Logging Application Block, the ability for a plugin to specify the "Log Source" is taken away:
"My LAB log entry",
//A "category" designation instead of "Log Source"
103, //Event ID
"Four Score And Seven Years Ago"
Of course the Logging Application Block allows a configuration file to direct category names to particular "Log Sources," but that does not allow the plugins to be distinguished when all plugins are logging to the "Performance" category.
Using just the BCL, my "Omega" and "Alpha" plugins' log entries have Log Source and category pairings like "Omega, Performance" or "Alpha, Security." With the Logging Application Block, I must re-assign the Log Source
to a fixed name instead of the dynamic plugin name, so that all my pairings instead look like "MyApp, Performance" or "MyApp, Security".
Can someone suggest which part of the Logging Application Block I should customize or extend to achieve the "dynamic" Log Source name behavior I need?
This is what I can think of right now. The FormattedEventLogTraceListener is being instantiated with the source parameter so you could opt to create a custom trace listener which just uses the functionalities provided by a FormattedEventLogTraceListener.
In the Write method, you would always instantiate a FormattedEventLogTraceListener passing in the source parameter you supplied (probably from a custom LogEntry class).
Global Technology & Solutions