[Mono-list] Diagnostic Messages
Jonathan Pryor
jonpryor@vt.edu
26 May 2002 12:42:49 -0400
Comments inline.
On Sun, 2002-05-26 at 10:26, A Rafael D Teixeira wrote:
>This need not be the case. Instead, the handy
>`System.Diagnostics.Trace' and `System.Diagnostics.Debug' classes could
>be used, which (by default, on Windows) do not display any console
>output. This would allow developers to still see the messages (if they
>need to), without having them be seen by end-users.
>
>The problem is that things don't behave this way under Mono, as the
>current `DefaultTraceListener' class sends all output messages to the
>console. I originally did this because it was easy, but I'd like to
>replace this with something more functional.
This really, isn't like what happens on Windows.
Correct. As detailed earlier, Trace- and Debug-generated messages are
sent through OutputDebugString on Windows. This can be demonstrated by
starting `DebugView' (available from
http://www.systeminternals.com/ntw2k/freeware/debugview.shtml) before
running a .NET program. Calls to {Trace|Debug}.WriteLine will appear in
the DebugView window, which is how I often view my trace/debug messages
without running the program from within a debugger.
>My current idea for "more functional" is that we add a new argument to
>mono/mint:
>
> --diagnostics=[trace | debug | all]
>
>If `--diagnostics' isn't present, then no diagnostic messages are
>generated. If `--diagnostics=trace', then only calls to
>`System.Diagnostics.Trace' would be displayed. Similarly, if
>`--diagnostics=debug', then only calls to `System.Diagnostics.Debug'
>would be displayed. `--diagnostics=all' would show messages sent to
>both `System.Diagnostics.Trace' and `System.Diagnostics.Debug'.
In windows I'm used to change the xml configuration file to disable at
run-time the DefaultTraceListener (remove from the Listeners collection) and
add a FileTraceListener to log problems in a separate file or to the
console. I would like that behaviour to work in Mono too, better than have a
switch in the interpreter/jitter.
I plan on implementing the functionality as well, but a
"reasonably-behaving" `DefaultTraceListener' class is higher on my
priority list.
Rafael Teixeira
Brazilian Developer
- Jon