17

I use TextWriterTraceListener (System.Diagnostics) in my application to trace several things like exceptions,...

The application is running on a terminal server and if there are many users using it simultaneously the listener starts to create many tracefiles with random GUIDs in the filename.

Are there possibilities or workarounds to avoid this behaviour ?

Mark Seemann
  • 225,310
  • 48
  • 427
  • 736
Kottan
  • 4,944
  • 9
  • 41
  • 67
  • I don't know if this is why dot net does this, but by creating multiple files, each file gets one user's interactions, instead of having multiple user's all intermixed. – Jay Jul 30 '19 at 18:05

3 Answers3

15

I've just taken a look at the documentation for TextWriterTraceListener and there's a note about 1/3 of the way down the page

If an attempt is made to write to a file that is in use or unavailable, the file name is automatically prefixed by a GUID

So, this would appear to be by design. If the file is indeed unavailable then there's nothing that can be done about it with the current implementation. What you could try doing is writing a custom implementation of TextWriterTraceListener that overrides the relevant Write/WriteLine methods so that the output goes to a file, per user, with a name that better suits your needs.

If what you want is for ALL logging from ALL users on the Terminal Server to go to a single file, then you'll almost certainly need to have some kind of "3rd party" process running that "owns" the file and synchronises writes to it, such as a Windows Service that is then called by your custom TextWriterTraceListener

Rob
  • 45,296
  • 24
  • 122
  • 150
  • 3
    This does not explain the situation I'm in, with a single application pool, running a single worker process, writing to a specified file name and *still* spamming multiple guid-named duplicate log files. There can be no other processes trying to access that file because only one is configured to use it. – Tom W Mar 19 '15 at 10:58
  • @TomW - I'm in the same situation. I think the parallel requests being processed by IIS are to blame. Maybe if there is a a log file per-thread it would behave better. – Tim Lewis Jul 27 '15 at 19:54
  • 1
    "only one user" is not the same as "only one process". Dot net library functions may well be spawning multiple processes. I'm still puzzled by the behavior. When I run on my laptop, I get a new GUID-named file every time I start up the app. But when I run on our test server, everything gets written to one big file. – Jay Jul 30 '19 at 18:02
0

Was the fix calling the Trace.Listeners.Add(xxx listener) multiple times on accident?

Because if you have multiple listeners added they write too all listeners when you call the Trace.writeline();

Also local IIS might be continueing to have the file in use when you shut down the application.

user3691679
  • 1
0

I am currently testing the addition of System.Diagnostics.Trace.Listeners.Clear() in my output method...

            // Upon a new day re-create the TextWriterTraceListener to update our file name...
            if (_date?.Day != DateTime.Now.Day) { _listener = null; }

            if (_listener == null)
            {
                System.Diagnostics.Trace.Listeners.Clear();

                _fileName = $"{DateTime.Now.ToString("yyyy-MM-dd")}_Trace.json";

                // Add a writer that appends to the trace.log file:
                _listener = new System.Diagnostics.TextWriterTraceListener(_fileName);

                _listener.IndentSize = 4;
                _listener.TraceOutputOptions = System.Diagnostics.TraceOptions.None; // TraceOptions.DateTime | TraceOptions.ThreadId;
                System.Diagnostics.Trace.AutoFlush = true;
                System.Diagnostics.Trace.Listeners.Add(_listener);

                // Obtain the Console's output stream, then add that as a listener...
                System.Diagnostics.Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));
            }
GuildOfCalamity
  • 61
  • 1
  • 7