Multiple Processes using one Logging Application Block log file

Question

We use the logging application block in our ASP.NET 2.0 application which is called in the following way:

public class BaseLogEntry : LogEntry
{
    public void CloseLog()
    {
        try
        {
            Logger.Writer.Dispose();
        }
        catch (Exception)
        { }
    }
}

public class GeneralLogEntry : BaseLogEntry
{
    /// <summary>
    /// 
    /// </summary>
    /// <param name="message"></param>
    public GeneralLogEntry(string message) : this(message, 2) { }

    /// <summary>
    /// 
    /// </summary>
    /// <param name="message"></param>
    /// <param name="priority"></param>
    public GeneralLogEntry(string message, int priority): base()
    {
        Categories.Add("General");
        Priority = priority;
        Severity = System.Diagnostics.TraceEventType.Information;
        Message = message;
        CloseLog();
    }
}

When we increase the number of worker processes in IIS above 1 the log files are prepended with a unique GUID like this:

068aa49c-2bf6-4278-8f91-c6b65fd1ea3aApplication.log

There are several log files generated by the app all of type "Rolling Flat File Trace Listener"

Is there a way to avoid this?

score 5 · Accepted Answer · edited Mar 12 '14 at 17:59

Originally from: http://ykm001.springnote.com/pages/6348311?print=1 (now a dead link redirecting to a game site):

Known problems

A GUID might be prepended to the filename of the log file A RollingFileTraceListener instance "owns" the log file it is writing to and locks it for exclusive write access when it writes the first log entry. It keeps the file locked until the instance is disposed. If another RollingFileTraceListener instance is created that points to the same file, before the first instance is disposed, the second instance cannot open this file for writing and will write to a new file with a GUID prepended to its name.

The RollingFileTraceListener indirectly derives from System.Diagnostics.TextWriterTraceListener. This class changes the filename to include a GUID when the file with the specified filename cannot be written to. This is because RollingFileTraceListener indirectly calls the EnsureWriter method on its base class TextWriterTraceListener. .NET Reflector shows this code for System.Diagnostics.TextWriterTraceListener.EnsureWriter() in System.dll (slightly rewritten to improve clarity):

try
{
    this.writer = new StreamWriter(fileNameWithPath, true, encoding1, 0x1000);
    break;
}
catch (IOException)
{
    Guid guid1 = Guid.NewGuid();
    fileName = guid1.ToString() + fileName;
    fileNameWithPath = Path.Combine(folderPath, fileName );
}

Basically it seems to be a known problem, there is a workaround at

http://entlibcontrib.codeplex.com/workitem/7472

Using the NoGUIDRollingFlatFileListener doesn't help, the problem still occurs (even after much time spent recompiling the logging application block). It might well be fixable in EntLib 4 but I'm stuck with Ent Lib 3.1

Perhaps I should look at alternative logging mechanisms

Multiple Processes using one Logging Application Block log file

1 Answers1