Geek Answers Handbook

When do I need more than one TraceSource in code?

If one application writes all its activity data to a single log file, is there any use of multiple TraceSource? I'm just curious about usage cases where more than one TraceSource is needed in the code.

+5
source share
1 answer

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

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

How to use TraceSource for different classes

I would say that at any time when you have more than one class, you can (possibly) consider using multiple TraceSource.

One of the benefits of having multiple TraceSource is that it increases the granularity with which you can manage logging. For example, if you use a different TraceSource in each class, you can control the record down to the class level. You can enable one or more special classes and disable all others.

This is a common template for NLog and log4net users. Typical class initialization using these 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 registrar for class A is named for the full class name (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 each class, you can easily manage logging by class.

I am not sure if this template is as common with TraceSource as it is with log4net and NLog. I think you can more often see that TraceSource users get their TraceSources by functional area.

So, you can divide your application into the functions "Read", "Process" and "Write" (or something important to you). In this case, you can 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 can enable logging for Read and disable logging for all other functional areas (or enable verbose logging for Read and less verbose logging for everyone else).

In addition, one of the parameters with TraceListeners is to display the name TraceSource. Thus, it will be easier to find out your logging at your output, because you could, if you wish, find all log messages created from a specific functional area (or a specific TraceSource) relatively easily.

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

Since you are looking at TraceSources, I would recommend that you look at this project on codeplex:

http://ukadcdiagnostics.codeplex.com/

This is a good project (based on TraceSource) that allows you to format the log output in the same way as you can with log4net and NLog.

I also encourage you to take a look at this workaround created around the Castle TraceSource.

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

The interesting thing they did was provide a TraceSource name hierarchy. I have implemented something similar in the past. It works very well.

My answer in this question gives an idea of ​​how the TraceSource hierarchy can be useful:

What is the best way to log?

Good luck

+9
source

More articles:


All Articles