Logging block creating 5d44be4f-40b7-49b1-a8c7-5d171fa0cfc3trace files

Topics: Logging Application Block
Aug 11, 2011 at 9:10 AM

Hi,

When using the logging block it writes the log entries to the correct file most of the time. It is however also creating additional files with something that resembles a GUID followed by the name the trace file should have. Those files contain random bits of logging info that should be in the main file.

I;m using the library in a cross thread app, but I understood that the trace listener is thread safe. I'm obviously doing something wrong as I dont seen any mention of this in the discussions I checked. Can somebody please have a look?

The way I call the trace listener (in the constructor of every class) is:

this._logger = EnterpriseLibraryContainer.Current.GetInstance();

My configuration file is:

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="true"/>
  </configSections>
  <loggingConfiguration name="" tracingEnabled="true" defaultCategory="General">
    <listeners>
      <add name="Flat File Trace Listener" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FlatFileTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FlatFileTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        fileName=".\trace.log" header="" footer="" formatter="Text Formatter" />
    </listeners>
    <formatters>
      <add type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        template="Timestamp: {timestamp} Message: {message}" name="Text Formatter" />
    </formatters>
    <categorySources>
      <add switchValue="All" name="General">
        <listeners>
          <add name="Flat File Trace Listener"/>
        </listeners>
      </add>
    </categorySources>
    <specialSources>
      <allEvents switchValue="All" name="All Events">
        <listeners>
          <add name="Flat File Trace Listener"/>
        </listeners>
      </allEvents>
      <notProcessed switchValue="All" name="Unprocessed Category"/>
      <errors switchValue="All" name="Logging Errors &amp; Warnings">
        <listeners>
          <add name="Flat File Trace Listener"/>
        </listeners>
      </errors>
    </specialSources>
  </loggingConfiguration>
</configuration>

 

Aug 11, 2011 at 10:07 AM

The GUID behavior happens when a rolling trace listener instance has the exclusive write access on the file and another rolling trace listener tries to write on that same file. Trace listeners are thread safe but writing on the same file is another thing. For a brief explanation kindly refer to this blog.

 

Noel Angelo Bolasoc
Global Technologies and Solutions
Avanade, Inc.
Contact Us

Aug 11, 2011 at 10:59 AM

Thanks for your quick response. I was under the impression that through the use of the Unity container it would always refer to the same logwriter instance and therefor write to the same file.

Would placing the logwriter instance in a singleton class solve this issue?

Aug 11, 2011 at 11:28 AM
Edited Aug 11, 2011 at 11:30 AM

I'm afraid it would not work, whether they have the same instance of logwriter or not. This is because you might be logging on the same file at the same time. The work around I can think of is to customize the trace listener and replace the part that prepends the GUID with some locking mechanism or you can use the Distributor Service. Hope this helps :)

 

Noel Angelo Bolasoc
Global Technologies and Solutions
Avanade, Inc.
Contact Us