Questions about app.config's <listeners> attributes

[Richard Lewis Haggard]

I'm modifying an existing piece of code that involves a custom trace
listener assembly but I simply don't understand the flow of control. How do
the bits and pieces fit together that implement and control a trace
listener? The existing Microsoft document that I've seen don't present
things in a manner that is meaningful to me so it would really be
appreciated if one of you more knowledgeable types who knows about this
would do the great favor of explaining in words of one syllable or less how
the individual parts of a custom trace listener interact with each other and
how the system knows how to hook them together.

Here's a related problem - what do the individual parts of the 'type'
attribute do? I've looked and looked but simply can't find a definition of
what information is supposed to go in the tag. Where does the 'name' value
get consumed? What does the first part of 'type' specify? Is it the name of
the object that implements the trace listener? And what's the second
argument, the 'Core.LogConsole' string do? Is it the assembly name as known
to the GAC that contains the trace listener object? And what about the
initializeData attribute?

<listeners>
<add name="LogConsoleListener" type="Core.Logging, Core.LogConsole,
Version=1.1.1.1, Culture=neutral;, PlublicKeyToken=1234abcd1234abcd"
initializeData="C:\Abc\Abc\Abc\" />
<listeners/>
--
Richard Lewis Haggard
www.Haggard-And-Associates.com

[Clint (cmueller]

I might be wrong on some parts here, but this is how I understand it
....

Type: This is broken into assembly, class, version, culture, public key
(obviously). In the example you had, this listener would exist in the
assembly Core.Logging. The listener's class name/type would be
Core.LogConsole. The assembly version number would be 1.1.1.1. The
culture and public key tokens, I'm not so sure about. I can only assume
they'd be used for globalization settings (which language, etc) and
identification, respectively.

Name: This is the listener's identification in the Listeners
collection. So, you can do
Trace.Listeners["LogConsoleListener"].DoSomething(); if you really
wanted to.

InitializeData: The data that you pass into the constructor of the
listener. In the case of TextWriterTraceListener, the example below
would create a file called "c:\abc\abc\abc\abc\" (Actually, this'd
error ... you'd need to tack on file.log or something, but you get the
point).

Hope this help - I'm sure someone'll be around sooner or later to
correct any mistakes I made.

Clint

[Richard Lewis Haggard]

Thanks.
After much failing about, I did manage to get the darned thing running
again.

I came up with a slightly different interpretation for the type string's two
parts.

Part-1) is the class that handles the trace logging functionality and is
mandatory.
Part-2) appears to be the name of the assembly that contains the class
specified in Part-1. It may or may not be present, depending upon the
implementation of the trace listener.
--
Richard Lewis Haggard
www.Haggard-And-Associates.com

"Clint (cm******@online.nospam)" <cj*******@gmail.com> wrote in message
news:11**********************@g10g2000cwb.googlegr oups.com...

I might be wrong on some parts here, but this is how I understand it
...

Type: This is broken into assembly, class, version, culture, public key
(obviously). In the example you had, this listener would exist in the
assembly Core.Logging. The listener's class name/type would be
Core.LogConsole. The assembly version number would be 1.1.1.1. The
culture and public key tokens, I'm not so sure about. I can only assume
they'd be used for globalization settings (which language, etc) and
identification, respectively.

Name: This is the listener's identification in the Listeners
collection. So, you can do
Trace.Listeners["LogConsoleListener"].DoSomething(); if you really
wanted to.

InitializeData: The data that you pass into the constructor of the
listener. In the case of TextWriterTraceListener, the example below
would create a file called "c:\abc\abc\abc\abc\" (Actually, this'd
error ... you'd need to tack on file.log or something, but you get the
point).

Hope this help - I'm sure someone'll be around sooner or later to
correct any mistakes I made.

Clint

[Clint (cmueller]

You're absolutely right on the Type string. I was just working with
these yesterday and had come across a problem with my listeners (in my
case, I needed the assembly string) and was thinking backwards. Sorry
for any confusion.

Clint