How are TraceSource names resolved in a .NET program?

Asked 13/12, 2012 at 21:28 Answered 13/12, 2012 at 23:7

The MSDN documentation for the TraceSource class has an example of how the app.config file can list out information for TraceSource instances:

http://msdn.microsoft.com/en-us/library/system.diagnostics.tracesource.aspx

However, there is no information on where the TraceSource values are stored...where are the existing TraceSource objects stored? When are they (edit: they means configured instances) constructed? How does the TraceSource object know how to return a named instance (edit: should be configured instance) instead of a new instance when creating a TraceSource object? Can I find a list of existing TraceSource objects without using Reflection?

Mischief answered 13/12, 2012 at 21:28 Comment(3)

Minor point: TraceSource is part of .NET, and so this applies to any .NET program. – Yellowknife 13/12, 2012 at 22:57

True, they are a .NET feature, not a C# one. – Mischief 14/12, 2012 at 3:38

You can still find a list of classes that uses TraceSource here referencesource.microsoft.com/#q=TraceSource – Cosmonaut 5/12, 2019 at 8:49

The TraceSource class keeps a private List of sources. But that isn't accessible by anyone but the TraceSource class itself.

The .config file section is meant to configure the listeners for a trace source. So when you create a TraceSource in your code, it uses the name you passed in the constructor and goes looking in the .config file to see what listeners should be added or removed automatically.

So code creates the a source, the .config file configures it. Not the other way around, a .config file cannot create a source.

Emulsifier answered 13/12, 2012 at 23:7 Comment(5)

Do you have a link to any sort of documentation that describes this? Do you know why M$ decided to keep the name of existing or configured TraceSources private inside the class? IMHO, seems like a design decision asking for trouble --- if a location in code creates a TraceSource instance with the same name as an existing instance or an instance configured in the app.config file, then traces would overlap. Why isn't querying whether a name exists or not possible? – Mischief 14/12, 2012 at 3:31

@Mischief trace has many usage scenarios and the designers in this case had in mind trace aimed at the developer who was writing and tracing his own code. There are scenarios where a server admin or user of a 3rd party library might want to see trace, but Systems.Diagnostics lacks some features for that such as discovery of TraceSources. On the other hand, it's a well known API so once they are discovered, wiring up listeners doesn't require recompile or access to the source code-- so win some, lose some. – Lashay 14/12, 2012 at 3:41

Nothing overlaps. Again, the name is only used to select listeners, not sources. Having more than one TraceSource with the same name is quite reasonable, it allows creating private trace sources that produce output in more than one class. Which is probably exactly why you want this feature. – Emulsifier 14/12, 2012 at 8:41

I do not agree with the statement that "Nothing overlaps." The TraceListeners of TraceSources named in the app.config file will overlap, which is confusing. If I write TraceSource tsOne = new TraceSource( "NamedSource" ); in one function, and TraceSource tsTwo = new TraceSource( "NamedSource" ); in another, tsOne and tsTwo will have the same (i.e. overlapping) listeners if "NamedSource" is in the app.config file (confirmed with VS2012). Even when tracing code within a single program, I think the danger is too large for TraceSources with one name but different expected listeners. – Mischief 14/12, 2012 at 13:49

Clearly it is my lack of imagination to understand why you would want sources with the same name to have different listeners. Just make a factory class that creates TraceSource objects and keeps them in a list so you can find them back. I don't otherwise understand what you do when you do find one back so that's all I can suggest. – Emulsifier 14/12, 2012 at 14:16

TraceSource objects stored?

In a static collection (so one copy per app domain), but in the .NET version, they are stored with weakreferences which can lead to memory leaks if too many are created. The mono version, if I remember correctly doesn't have this problem.

For details, I recommend reading the source-- the Mono sources are easier to track down because they are officially open.

When are they constructed?

When the app that is writing trace writes TraceSource source = new TraceSource();

How does the TraceSource object know how to return a named instance instead of a new instance when creating a TraceSource object?

Not sure.

Can I find a list of existing TraceSource objects without using Reflection?

Used to be able to do this with RedGate Reflector. System.Net and the WCF libraries use Systems.Diagnostics, but few other do. There isn't a way in the API to just interogate the runtime for current trace sources, it would have been a nice feature.

Lashay answered 13/12, 2012 at 23:7 Comment(2)

Do you have a link to official M$ documentation that describes the details above, or did you happen on a random copy of the source code and look at it? :) – Mischief 14/12, 2012 at 3:33

Here is one copy: reflector.webtropy.com/default.aspx/Dotnetfx_Vista_SP2/… and Here is the way to view it legally too: hanselman.com/blog/… – Lashay 14/12, 2012 at 3:36

Recommended topics

Hot tags