Can you check if you have another external application or logging mechanism on another application domain that is also writing to the same file? Also, can you check in your code if it is locking the logfile for so long that other tracelisteners can't
right into it? This behavior is explained on this
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):
this.writer = new StreamWriter(fileNameWithPath, true, encoding1, 0x1000);
Guid guid1 = Guid.NewGuid();
fileName = guid1.ToString() + fileName;
fileNameWithPath = Path.Combine(folderPath, fileName );
I'm also not sure what do you mean by this: "I log that information through the enterprise logging block, and into a text file".
Do you mean that you are writing to the same file in two different mechanisms? Through Enterprise Library and through a custom code? If yes, then that would be the cause of your issue.
Noel Angelo Bolasoc
Global Technologies and Solutions