iis - 使用一个日志记录应用程序 block 日志文件的多个进程

Question

我们在 ASP.NET 2.0 应用程序中使用日志记录应用程序 block ，其调用方式如下:

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

应用程序生成了多个日志文件，所有类型均为“滚动平面文件跟踪监听器”

有办法避免这种情况吗？

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 没有帮助，问题仍然发生(即使在花费大量时间重新编译日志记录应用程序 block 之后)。它很可能可以在 EntLib 4 中修复，但我坚持使用 Ent Lib 3.1

也许我应该考虑替代日志机制