Tracing

[RedLars]

Hi

Does the class System.Diagnost ics.Trace use a singelton ?

I'm able to do this;
System.Diagnost ics.Trace.Write Line("test");

However, these give compiler errors;
System.Diagnost ics.Trace myTrace = new System.Diagnost ics.Trace; // A
new expression requires () or []
System.Diagnost ics.Trace myTrace = new System.Diagnost ics.Trace(); //
No constructors defined

So there can only be one Trace instance within a .NET application, is
that correct?

What would happen in the following situation. An main application has
a Logger class with 3-4 WriteXXX methods (a singelton class) that
formats the input in a specifc way and writes it to Trace.WriteLine
method that is setup to write to an ascii file. Then we have a
lightweight plugin that uses Trace::WriteLin e("...") without any
particular formating in the message and then writes data to the
OutputDebugStri ng. What will happen if the main application loads the
plugin?

I'm guessing it will affect the Trace behaviour - the plugin will
'lose' the OutputDebugStri ng property and instead send unformated
strings to main application log file.

[Peter Duniho]

On Wed, 29 Oct 2008 00:27:21 -0700, RedLars <Li***********@ gmail.com>
wrote:

Hi

Does the class System.Diagnost ics.Trace use a singelton ?

The methods are static. I suppose internally it could be implemented as a
singleton, but I don't know why it would be. I haven't looked, but I
think it's more likely it's just effectively a plain, static class.

[...]
What would happen in the following situation. An main application has
a Logger class with 3-4 WriteXXX methods (a singelton class) that
formats the input in a specifc way and writes it to Trace.WriteLine
method that is setup to write to an ascii file. Then we have a
lightweight plugin that uses Trace::WriteLin e("...") without any
particular formating in the message and then writes data to the
OutputDebugStri ng. What will happen if the main application loads the
plugin?

That depends on how you've configured the tracing.

Personally, I find the tracing functionality in .NET to be unnecessarily
complicated. I have seen recommendations for Log4net, and you may want to
look into that. I haven't used it myself, but everyone else seems to
think it's much better. :)

If you do want to use the .NET trace stuff, it's helpful to keep in mind
that three different classes work together to control what actually goes
out: TraceListener (which does the actual logging), TraceSource (which
defines a particular association for specific trace output), and
TraceSwitch (which controls what tracing is enabled for a particular
source).

My recollection is that you can set things up so that your TraceListener
doesn't necessarily output stuff that's written using the plain Trace
methods. By adding it only to the listeners for a TraceSource, then only
when you output to that source will that listener write output. And of
course, the plug-in shouldn't have access to that source.

Unfortunately, the docs mostly assume that you will be using an .config
file to control tracing. I found the documentation to be very unhelpful
for controlling tracing programmaticall y. But I was able to get things
set up the way I wanted through some trial and error and a bit of
guesswork. If I could remember more details off the top of my head, I'd
post them now, but I don't. Sorry. I can probably dig up some sample
code I wrote if you decide you want to keep using the .NET trace stuff and
are having trouble (though, even what I did come up with wasn't all that
complicated...f or advanced use of the .NET trace mechanism you'll need a
better resource than me).

Pete