Несколько процессов, использующих один файл журнала блокировки приложения

Question

Мы используем блок приложения ведения журнала в нашем приложении ASP.NET 2.0, которое вызывается следующим образом:

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();
    }
}

Когда мы увеличиваем число рабочих процессов в IIS выше 1, к файлам журнала добавляется уникальный GUID, например:

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

Существует несколько файлов журнала, сгенерированных приложением, все типа "Rolling Flat File Trace Listener"

Есть ли способ избежать этого?

Answer 1

Первоначально из: http://ykm001.springnote.com/pages/6348311?print=1 (теперь неработающая ссылка, перенаправляющая на игровой сайт):

Известные проблемы

GUID может быть добавлен к имени файла журнала. Экземпляр RollingFileTraceListener "владеет" файлом журнала, в который он записывает, и блокирует его для монопольного доступа при записи первой записи журнала. Он сохраняет файл заблокированным, пока экземпляр не будет удален. Если создается другой экземпляр RollingFileTraceListener, который указывает на тот же файл, перед удалением первого экземпляра, второй экземпляр не сможет открыть этот файл для записи и запишет в новый файл с GUID, предварительно добавленным к его имени.

RollingFileTraceListener косвенно происходит от System.Diagnostics.TextWriterTraceListener. Этот класс изменяет имя файла для включения GUID, когда файл с указанным именем файла не может быть записан. Это связано с тем, что RollingFileTraceListener косвенно вызывает метод EnsureWriter для своего базового класса TextWriterTraceListener. .NET Reflector показывает этот код для System.Diagnostics.TextWriterTraceListener.EnsureWriter() в System.dll (слегка переписан для большей ясности):

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 );
}

В основном это кажется известной проблемой, есть обходной путь в

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

Использование NoGUIDRollingFlatFileListener не помогает, проблема все еще возникает (даже после того, как много времени ушло на перекомпиляцию блока приложения ведения журнала). Это может быть исправлено в EntLib 4, но я застрял с Ent Lib 3.1

Возможно, мне стоит взглянуть на альтернативные механизмы регистрации