EventLogTraceListener incompatible with typical usage of Trace?

[Ken]

I would like to start using EventLogTraceListener, and am running into
a couple of significant limitations:

1) I have found that there is no way to write EventLog entries with
different EventLogEntryTypes. It seems that EventLogTraceListener is
only capable of writing entries with EventLogEventType.Informat*ion,
even for Trace.Fail. Is this assessment correct?

2) EventLogTraceListener.Flush (and the idea of buffering writes) is
not applicable to EventLogTraceListener. It seems that each call to
Trace.Write() or Trace.WriteLine() results in the creation of a new
EventLog entry.

This behavior is undesirable and incompatible with my usage of
Trace.Write() and Trace.WriteLine(). For example:

try
{
// Remove the DefaultTraceListener
Trace.Listeners.Clear();

// Create EventLogTraceListener with an EventSource of "Test"
EventLogTraceListener evListener = new EventLogTraceListener("Test");
// Register the listener
Trace.Listeners.Add(evListener);

// Raise an exception
throw new Exception("Fake exception");
}
catch(Exception ex)
{
// Construct trace output message with date and exception info
Trace.Write(System.DateTime.No*w.ToString());
Trace.Write(ex.GetType().Name)*;
Trace.Write(ex.Message);
Trace.Write("\r\n");
Trace.WriteLine(ex.StackTrace)*;
}

The code above uses Write() and WriteLine() in the way that I believe
they were intended, based on the presence of other formatting methods
for intentation. This use of Trace works great for file logging.

If I add the EventLogTraceListener, however, the above code
will create five entries in the EventViewer, no matter how I use
Trace.AutoFlush and Trace.Flush(). This means that
EventLogTraceListener is essentially unusable for me if I have
widespread usage of Trace like that above.

Subclassing TraceListener to create a listener that writes "correctly"
to the EventViewer is not a viable option because the Trace class has
no members that would help to group a series of Write()/WriteLine()
calls into a a single logical log entry.

So ultimately, it is not possible to use Trace's
Write()/WriteLine()/buffering capabilities (standard for logging to
files and console) AND create meaningful EventViewer entries. This
seems like an oversight in the design of the Trace API.

Please comment; I would gladly be proven wrong on either point,
especially #2.

Ken

[serge calderara]

Tracing works fine for both cases, but you have to remember that each write
operation is a single entry , where ever this entry goes, file or eventlog.

For event log if you want a single entry, simply build your complete string
message before wrtiting it. This is the way I use it

Don't forget also that EventLogTraceLisner send EvenLog object.
You coudl you also directly the EventLog class

HOpe it helps

"Ken" wrote:

I would like to start using EventLogTraceListener, and am running into
a couple of significant limitations:

1) I have found that there is no way to write EventLog entries with
different EventLogEntryTypes. It seems that EventLogTraceListener is
only capable of writing entries with EventLogEventType.InformatÂ*ion,
even for Trace.Fail. Is this assessment correct?

2) EventLogTraceListener.Flush (and the idea of buffering writes) is
not applicable to EventLogTraceListener. It seems that each call to
Trace.Write() or Trace.WriteLine() results in the creation of a new
EventLog entry.

This behavior is undesirable and incompatible with my usage of
Trace.Write() and Trace.WriteLine(). For example:

try
{
// Remove the DefaultTraceListener
Trace.Listeners.Clear();

// Create EventLogTraceListener with an EventSource of "Test"
EventLogTraceListener evListener = new EventLogTraceListener("Test");
// Register the listener
Trace.Listeners.Add(evListener);

// Raise an exception
throw new Exception("Fake exception");
}
catch(Exception ex)
{
// Construct trace output message with date and exception info
Trace.Write(System.DateTime.NoÂ*w.ToString());
Trace.Write(ex.GetType().Name)Â*;
Trace.Write(ex.Message);
Trace.Write("\r\n");
Trace.WriteLine(ex.StackTrace)Â*;
}

The code above uses Write() and WriteLine() in the way that I believe
they were intended, based on the presence of other formatting methods
for intentation. This use of Trace works great for file logging.

If I add the EventLogTraceListener, however, the above code
will create five entries in the EventViewer, no matter how I use
Trace.AutoFlush and Trace.Flush(). This means that
EventLogTraceListener is essentially unusable for me if I have
widespread usage of Trace like that above.

Subclassing TraceListener to create a listener that writes "correctly"
to the EventViewer is not a viable option because the Trace class has
no members that would help to group a series of Write()/WriteLine()
calls into a a single logical log entry.

So ultimately, it is not possible to use Trace's
Write()/WriteLine()/buffering capabilities (standard for logging to
files and console) AND create meaningful EventViewer entries. This
seems like an oversight in the design of the Trace API.

Please comment; I would gladly be proven wrong on either point,
especially #2.

Ken

[Ken]

Serge,

I understand what you're saying and agree that constructing the full
trace message prior to calling Trace.WriteLine() will get me what I
want.

I would submit, however, that the Trace's interface suggest an intended
usage much like a StreamWriter. This allows you to conveniently write
Trace information out to whatever persistence store you want. This
makes perfect sense for logging to a file or console (which is what
most of the examples illustrate), but it doesn't work so well with
stores that have a concept of a "record" like the eventlog or a
database. A critically important feature of Trace is that you can
dynamically determine who the listeners are, and Trace never needs to
care about who the listeners are. If you have to use Trace differently
depending on who is listening, you're taking away this key feature.

Ken