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?

Answer 1

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