6

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?

Matt
  • 61
  • 3

2 Answers2

2

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 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? – Matt Dec 14 '12 at 03:31
  • @Matt 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. – MatthewMartin Dec 14 '12 at 03: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. – Hans Passant Dec 14 '12 at 08: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. – Matt Dec 14 '12 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. – Hans Passant Dec 14 '12 at 14:16
0

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.

MatthewMartin
  • 32,326
  • 33
  • 105
  • 164
  • 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? :) – Matt Dec 14 '12 at 03:33
  • Here is one copy: http://reflector.webtropy.com/default.aspx/Dotnetfx_Vista_SP2/Dotnetfx_Vista_SP2/8@0@50727@4016/DEVDIV/depot/DevDiv/releases/whidbey/NetFxQFE/ndp/fx/src/CompMod/System/Diagnostics/TraceSource@cs/1/TraceSource@cs and Here is the way to view it legally too: http://www.hanselman.com/blog/NETFrameworkLibrarySourceCodeAvailableForViewing.aspx – MatthewMartin Dec 14 '12 at 03:36