When do I need more than one TraceSource in code?

Question

If one application is writing all its activity data in one log file, is there any use of having more than one TraceSource? I am just curious about the uses cases where one will need more than one TraceSource in the code.

Answer 1

See these answers to other questions for a good starting point on using TraceSources:

can't understand .net 2010 tracing and app.config

How to use TraceSource across classes

I would say that any time you have more than one class you might (might) consider having more than one TraceSource.

One advantage to having more than one TraceSource is that it increases the granularity at which you can control your logging. For example, if you use a different TraceSource in every class, then you could control the logging down to the class level. You could turn on one (or more) specific classes and turn off all others.

This is a common pattern for users of NLog and log4net. Typical initialization of classes using those logging platforms will look something like this:

public class A
{
  //NLog example
  private static Logger logger = LogManager.GetCurrentClassLogger();

  public F()
  {
    logger.Info("Inside F");
  }
}

In this example, the logger for class A is named for the fully qualified name of the class (NLog does the hard work in GetCurrentClassLogger()).

To do something similar with TraceSource, you would do something like this:

public class A
{
  private static TraceSource ts = new TraceSource(System.Reflection.GetCurrentMethod().DeclaringType.ToString();

  public F()
  {
    ts.Information("Inside F");
  }
}

If you did this in every class, you could easily control you logging by class.

I'm not so sure that this pattern is as common with TraceSource as it is with log4net and NLog. I think that you might more often see users of TraceSource get their TraceSources by functional area.

So, you might divide your app up into "Read", "Process", and "Write" functionality (or whatever makes sense for you). In that case, you could get the appropriate TraceSource in your classes based on the functional area in which they are used:

public class FileReader
{
  private static TraceSource ts = new TraceSource("Read");

  public F()
  {
    ts.Information("Hello from FileReader.F");
  }
}

public class NetworkReader
{
  private static TraceSource ts = new TraceSource("Read");

  public F()
  {
    ts.Information("Hello from NetworkReader.F");
  }
}

And so on.

Now you could turn logging on for "Read", and off for all other functional areas (or turn on verbose logging for "Read" and less verbose logging for all others).

In addition, one of the options with TraceListeners is to output the TraceSource name. So, in your output it will easier to make sense of your logging because you could, if you choose to do so, relatively easily find all logging messages that are generated from a particular functional area (or by a particular TraceSource).

If you have a good namespace naming convention, you could even consider getting the TraceSource for each class based on some node in the namespace hierarchy or even based on the assembly that the class lives in. There are .NET calls for a Type that will retrieve that information for you.

Since you are looking at TraceSources, I would encourage you to look at this project at codeplex:

http://ukadcdiagnostics.codeplex.com/

It is a nice project (based on TraceSource) that allows you to format your logging output in a similar fashion to what you can do with log4net and NLog.

I would also encourage you to take a look at this logging wrapper built around TraceSource from Castle.

https://github.com/castleproject/Castle.Core/blob/master/src/Castle.Core/Core/Logging/TraceLogger.cs

The interesting thing that they have done is to provide a hierarchy to TraceSource names. I have implemented something similar in the past. It works out pretty well.

My answer in this question provides an idea for how a TraceSource hierarchy can be beneficial:

What's the best approach to logging?

Good luck!