Background: Ah, the joys of reading documentation...
The Remarks section of: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfaddelementforlistenerselement.asp specifies that the `Debug' and `Trace' classes share the same Listeners collection. My own tests confirm this, and the current Mono implementation of these classes also has them share the listeners, primarily because they're both just wrappers to `TraceImpl'. What this means is that it would be difficult to modify the `DefaultTraceListener' so that if it was called from `Debug' it would do one thing, and do something else if called from `Trace'. (Not impossible, just not trivial. Arguably such behavior would be undesirable, as it would introduce incompatibilities with .NET. However, some of the proposals also introduce incompatibilities, so there are trade-offs everywhere.) That, for me, kills my suggestion for a ``--diagnostic'' argument for mint/mono. However, I still don't like how the `DefaultTraceListener' currently works. It always sends output to the console, which may be undesirable. (There's also the fact that the console output it generates is ugly, but that's a different matter.) Apparently several of you agree: by default you don't want to see the output of the `DefaultTraceListner' class. I'm inclined to agree. Which raises a question for me: how should we specify how `DefaultTraceListener' should behave? Note that application configuration files do not enter the picture here, as the config file would only allow you to add or remove the `DefaultTraceListener', and not change its behavior in any major way. If this is incorrect, please let me know, but this is my current understanding of the .config file schema. The proposals: Proposal 1: Never send output to the console. The `DefaultTraceListener' has a `LogFileName' property that can be set if a log file should be generated, so console output isn't strictly necessary. My issue with this solution is that setting `LogFileName' can't be done from a configuration file (that I could determine), and would thus require explicit programmer support. Thus, this proposal is the equivalent to saying: "Ignore the `DefaultTraceListener'. If you want to see diagnostic messages, create an application configuration file and add another listener." I don't like this solution, as (1) application configuration files aren't currently supported on Mono, and (2) I can't make the application configuration files work on .NET. (It keeps complaining that it can't find the `System.Diagnostics.TextWriterTraceListener' class, which is annoying me, especially since I'm copying the SDK examples.) Proposal 2: Always send output to the console. This is the current situation (assuming that you compiled your C# code with the DEBUG or TRACE symbols set). I don't believe it to be sufficiently flexible, and could lead people to remove diagnostic messages from their code if diagnostic messages will always be present. Proposal 3: Use a MONO_TRACE environment variable. This is based on what Paolo Molaro suggested. By default, no messages are sent to the console. If output is desired from the `DefaultTraceListener', set the MONO_TRACE environment variable. Three value categories would be recognized: Console.Out: send output to standard output Console.Error: send output to standard error <anything else>: Treat <anything else> as a file, and assign this value to the `LogFileName' property. This would have the effect of writing diagnostic messages to the specified file. Both `Console.Out' and `Console.Error' would take a "prefix" that is prefixed before all diagnostic messages, allowing them to be separated from normal program output. For example: MONO_TRACE="Console.Out:** " The prefix would be everything after the first ':'. The downside with this proposal is that it introduces an incompatibility with .NET, as .NET won't support the MONO_TRACE variable. I don't consider this to be significant, as .NET supports `OutputDebugString', which I find to be a preferable solution anyway. I prefer Proposal 3, but I'm willing to implement any of these proposals (or others, if suggested). Thanks, - Jon _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
