Question

I’m trying to use System.Diagnostics to do some very basic logging. I figure I’d use what’s in the box rather than taking on an extra dependency like Log4Net or EntLib.

I’m all set up, tracing is working wonderfully. Code snippet:

Trace.TraceInformation("Hello World")

App.config:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.diagnostics>
    <trace autoflush="true" indentsize="4">
      <listeners>
        <add name="TraceListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="Trace.log" traceOutputOptions="DateTime" />
        <remove name="Default" />
      </listeners>
    </trace>
  </system.diagnostics>
</configuration>

and my little “Hello World” shows nicely up in my Trace.log file. But now I’d like to switch OFF tracing, so I dig into MSDN and find How to: Configure Trace Switches
. I add the <switches> element, and now my app.config looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.diagnostics>
    <trace autoflush="true" indentsize="4">
      <listeners>
        <add name="TraceListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="Trace.log" traceOutputOptions="DateTime" />
        <remove name="Default" />
      </listeners>
    </trace>
    <switches>
      <add name="Data" value="0" />
    </switches>
  </system.diagnostics>
</configuration>

The value="0" should turn off tracing – at least if you then follow How to: Create and Initialize Trace Switches, which tells you to add this line of code:

Dim dataSwitch As New BooleanSwitch("Data", "DataAccess module")

That doesn’t make sense to me: I just have to declare an instance of the BooleanSwicth to be able to manage (disable) tracing via the .config file? Should I like … use … the object somewhere?

Anyways, I’m sure I missed something really obvious somewhere. Please help.

How do I switch OFF tracing in app.config?

Answer 1

I agree with @Alex Humphrey’s recommendation to try using TraceSources. With TraceSources you gain more control over how your logging/tracing statements execute. For example, you could have code like this:

public class MyClass1
{
  private static readonly TraceSource ts = new TraceSource("MyClass1");

  public DoSomething(int x)
  {
    ts.TraceEvent(TraceEventType.Information, "In DoSomething.  x = {0}", x);
  }
}

public class MyClass2
{
  private static readonly TraceSource ts = new TraceSource("MyClass2");

  public DoSomething(int x)
  {
    ts.TraceEvent(TraceEventType.Information, "In DoSomething.  x = {0}", x);
  }
}

The TraceSource.TraceEvent call will automatically check the level of the message (TraceEventType.Information) against the configured level of the associated Switch and will determine whether or not the message should actually be written out.

By using a differently named TraceSource for each type, you can control the logging from those classes individually. You could enable MyClass1 logging or you could disable it or you could enable it but have it log only if the level of the message (TraceEventType) is greater than a certain value (maybe only log “Warning” and higher). At the same time, you could turn logging in MyClass2 on or off or set to a level, completely independently of MyClass1. All of this enabling/disabling/level stuff happens in the app.config file.

Using the app.config file, you could also control all TraceSources (or groups of TraceSources) in the same way. So, you could configure so that MyClass1 and MyClass2 are both controlled by the same Switch.

If you don’t want to have a differently named TraceSource for each type, you could just create the same TraceSource in every class:

public class MyClass1
{
  private static readonly TraceSource ts = new TraceSource("MyApplication");

  public DoSomething(int x)
  {
    ts.TraceEvent(TraceEventType.Information, "In DoSomething.  x = {0}", x);
  }
}

public class MyClass2
{
  private static readonly TraceSource ts = new TraceSource("MyApplication");

  public DoSomething(int x)
  {
    ts.TraceEvent(TraceEventType.Information, "In DoSomething.  x = {0}", x);
  }
}

This way, you could make all logging within your application happen at the same level (or be turned off or go the same TraceListener, or whatever).

You could also configure different parts of your application to be independently configurable without having to go the “trouble” of defining a unique TraceSource in each type:

public class Analysis1
{
  private static readonly TraceSource ts = new TraceSource("MyApplication.Analysis");

  public DoSomething(int x)
  {
    ts.TraceEvent(TraceEventType.Information, "In DoSomething.  x = {0}", x);
  }
}

public class Analysis2
{
  private static readonly TraceSource ts = new TraceSource("MyApplication.Analysis");

  public DoSomething(int x)
  {
    ts.TraceEvent(TraceEventType.Information, "In DoSomething.  x = {0}", x);
  }
}

public class DataAccess1
{
  private static readonly TraceSource ts = new TraceSource("MyApplication.DataAccess");

  public DoSomething(int x)
  {
    ts.TraceEvent(TraceEventType.Information, "In DoSomething.  x = {0}", x);
  }
}

public class DataAccess2
{
  private static readonly TraceSource ts = new TraceSource("MyApplication.DataAccess");

  public DoSomething(int x)
  {
    ts.TraceEvent(TraceEventType.Information, "In DoSomething.  x = {0}", x);
  }
}

With your class instrumented this way, you could make the “DataAccess” part of your app log at one level while the “Analysis” part of your app logs at a different level (of course, either or both parts of your app could be configured so that logging is disabled).

Here is a part of an app.config file that configures TraceSources and TraceSwitches:

<system.diagnostics>
  <trace autoflush="true"></trace>
  <sources>
    <source name="MyClass1" switchName="switch1">
      <listeners>
        <remove name="Default"></remove>
        <add name="console"></add>
      </listeners>
    </source>
    <source name="MyClass2" switchName="switch2">
      <listeners>
        <remove name="Default"></remove>
        <add name="console"></add>
      </listeners>
    </source>
  </sources>
  <switches>
    <add name="switch1" value="Information"/>
    <add name="switch2" value="Warning"/>
  </switches>
  <sharedListeners>
    <add name="console"
         type="System.Diagnostics.ConsoleTraceListener">
    </add>
    <add name="file"
         type="System.Diagnostics.TextWriterTraceListener"
         initializeData="trace.txt">
    </add>
  </sharedListeners>
</system.diagnostics>

As you can see, you could configure a single TraceSource and a single Switch and all logging would occur with a single level of control (i.e. you could turn all logging off or make it log at a certain level).

Alternatively, you could define multiple TraceSources (and reference the corresponding TraceSources in your code) and multiple Switches. The Switches may be shared (i.e. multiple TraceSources can use the same Switch).

Ultimately, by putting in a little more effort now to use TraceSources and to reference appropriately named TraceSources in your code (i.e. define the TraceSource names logically so that you can have the desired degree of control over logging in your app), you will gain significant flexibility in the long run.

Here are a few links that might help you with System.Diagnostics as you go forward:

.net Diagnostics best practices?

Logging best practices

What's the best approach to logging?

Does the .Net TraceSource/TraceListener framework have something similar to log4net's Formatters?

In the links I posted, there is often discussion of the “best” logging framework. I am not trying to convince you to change from System.Diagnostics. The links also tend to have good information about using System.Diagnostics, that is why I posted them.

Several of the links I posted contain a link to Ukadc.Diagnostics. This is a really cool add on library for System.Diagnostics that adds rich formatting capability, similar to what you can do with log4net and NLog. This library imposes a config-only dependency on your app, not a code or reference dependency.