guid-logfile created by Exception Handling Block?

Topics: User Discussion
Sep 17, 2008 at 9:42 PM
Hi,
I have the following configuration:
1. Exception Policy uses 2 Logging Handlers :
  a - 1st one uses the Category Source, EVENT,  that writes to a Event Log using the Event Log Trace Listener
  b - 2nd one uses a Category Source, ERROR, that  writes to the Log File using the Flat File Log Trace Listener
2. One more Category Source, DEBUG, that writes to the same Log File using a different Flat File Log Trace Listener. Different because I want different formats for DEBUG and ERROR messages.

When the exception policy is triggered, it writes to the event log successfully but instead of writing to the specified Log File, it writes  to a new log file - (guid-logfilename).
I read somewhere that this happens bcoz of multiple trace listener pointing to the same log file.

but how do I avoid this situation?
I need different trace listener because I need to use different formats. And I don't have the option of writing to a separate file.

Please advise!
hpdotnet



Oct 6, 2008 at 5:15 PM
Hi,
Can anyone help me on this problem? Any comments/suggestions will be greatly appreciated.

Thanks
hp
Mar 18, 2009 at 6:48 PM
Edited Mar 18, 2009 at 6:50 PM
Hi,
This may be too late to help, but others may be having the same trouble (as I just did).  The flat file trace listener is derived from System.Diagnostics.TextWriterTraceListener which is in the .net framework.  When the logging application block's (LAB) flat file trace listener goes to write something to the log, it ultimately calls one of the Write methods of the TextWriterTraceListener.  These write methods all call the method EnsureWriter() to open a StreamWriter to the file name you defined in your flat file log trace listener config.  If a stream writer cannot be opened, the EnsureWriter method prefixes the file name with a guid and tries to open a stream to the new file name.  The problem is that the Close() ( or Dispose() ) method of one trace listener is not being called before a separate instance of the trace listener tries to write to the same log file.  I ran into this problem because I have multiple assemblies (a windows service and a asp.net application) that are both using the LAB to write to the same log file.  This isn't going to work because the web app may have the log file locked at the same time the service tries to write to the very same log file.  In my case, I think what I need to do is use the distributor service of the LAB to send all message through a message queue and then log them on the other side of the queue.

Hope this helps.