Event Log / Log Source (non-configurable)

Topics: Logging Application Block
Apr 29, 2009 at 9:37 PM
Edited Apr 30, 2009 at 9:09 PM
After a log source has been configured and successfully used with a particular event log (e.g. "Application" log), subsequent attempts to re-assign the log source to a different event log (e.g. "MyCustomLog") fail, and a log entry records the failure:

Timestamp: 4/28/2009 9:27:02 PM<o:p></o:p>

Message: Tracing to LogSource 'Correctness' failed. Processing for other sources will continue. See summary information below for more information. Should this problem persist, stop the service and check the configuration file(s) for possible error(s) in the configuration of the categories and sinks.<o:p></o:p>

<o:p> </o:p>
Summary for <st1:city w:st="on"><st1:place w:st="on">Enterprise</st1:place></st1:city> Library Distributor Service:<o:p></o:p>

======================================
-->
Message:
Timestamp: 4/28/2009 9:27:01 PM
Message: Test of EntLib logging. I've changed the event log from "Application" to "MyCustomLog"
Category: Performance, Correctness
Severity: Information<o:p>
</o:p>
Exception Information Details:
======================================
Exception Type: System.ArgumentException<o:p></o:p>

Message: The source 'Beta' is not registered in log 'MyCustomLog'. (It is registered in log 'Application'.) " The Source and Log properties must be matched, or you may set Log to the empty string, and it will automatically be matched to the Source property.<o:p></o:p>

In other words, it is not sufficient to simply adjust the app config file...because further steps are needed to wipe out a log source from the registry (and the system event log might require a system reboot as well).  This makes the exercise more of an "installation" task, rather than a "configuration" task.

So I am curious:

1) Is there a prescribed way to programmatically address this problem?
2) Will the next EntLib release tackle this?
3) Why this oversight?  Is it because the system event log is just one of many log types, and EntLib was not yet prepared to cater to the nuances of just this one particular?  Is there an attitude that re-assigning a log source is the task of a developer, not an end-user, and therefore this booby-trap is low priority?  A "yes" answer for those last two questions is fine, but I'm just curious.

Currently, the only way I can see to tackle this problem is to warn that EntLib app config settings for "log source to event log" are off limits, and instead adjust them using component installers.

How has the community handled this?
Apr 30, 2009 at 6:45 AM
How did you create the custom event source?  Did you reconfigure the Log and Source property of your FormattedEventLog TraceListener?



Sarah Urmeneta
Global Technology & Solutions
Avanade, Inc.
entlib.support@avanade.com
Apr 30, 2009 at 9:06 PM
Edited Apr 30, 2009 at 9:11 PM
I created the custom event source using a trace listener configuration attribute.  I started with this:

<

listeners>
  <
add source="Beta" formatter="Text Formatter" log="Application" machineName="" listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FormattedEventLogTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" traceOutputOptions="None" filter="All" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FormattedEventLogTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
name="My Beta Logging" />
</
listeners>
<
categorySources>
  <
add switchValue="All" name="Correctness">
    <
listeners>
      <
add name="My Beta Logging" />
    </
listeners>
  </
add>
</
categorySources>

I ran the code, logging to the "Correctness" category, and successfully placed an entry in the "Application" log designated as a "Beta" source.  I then stopped the program and changed the trace listener log attribute (listeners/add/@log) from "Application" to "MyLog".  I re-ran the program and got the error I listed above.

The problem is that there needs to be a call to destroy the "Beta" log source from the "Application" log, like this:

EventLog.DeleteEventSource("Beta");  

But once I edit the app config file, as I did above, EntLib does not know to perform that cleanup step.  This strikes me as the kind of problem the documentation would cover, or that there may be a special solution for (other than me directly doing the cleanup myself).

May 4, 2009 at 7:02 AM
Shouldn't you be configuring the Source property rather than the Log property?  If you want to log to a different log other than the  "Application" log, you should first create it:

Create a "MyLog" log with "MySource"
EventLog.CreateEventSource("MySource", "MyLog");

Your FormattedEventLogTraceListener should have these properties set:
Log: MyLog
Source: MySource

If you want to log again to MyLog using different source, create another eventsource:
EventLog.CreateEventSource("AnotherSource", "MyLog");

Set the Source property of the FormattedEventLogTraceListener property to "AnotherSource". 

Is this what you're trying to accomplish?


Sarah Urmeneta
Global Technology & Solutions
Avanade, Inc.
entlib.support@avanade.com