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

Question

In my app.config I want to set 3 tracing levels (switches?): verbose, warning and none. In the debug version of the code, I want the verbose switch to be active, in the release I want warning. In special cases my application users can modify the config file to disable all traces.

I want debug traces to output on the console, while release traces only to a log file.

I',ve written the following:

[...]
<system.diagnostics>
        <sources>
            <!-- This section defines the logging configuration for My.Application.Log -->
          <source name="debug" switchName="debug">
            <listeners>
              <add name="FileLog"/>
              <add name="console"/>
            </listeners>
          </source>

          <source name="release" switchName="release">
            <listeners>
              <add name="FileLog"/>
            </listeners>
          </source>

          <source name="silent" switchName="none">
            <listeners/>
          </source>
        </sources>


        <switches>
            <add name="debug" value="Verbose"/>
            <add name="release" value="Warning"/>
            <add name="none" value="Off"/>
        </switches>


        <!--<sharedListeners>
            <add name="FileLog" type="System.Diagnostics.TextWriterTraceListener"  traceOutputOptions="DateTime" initializeData="felix.log"/>
            <add name="console" type="System.Diagnostics.ConsoleTraceListener" initializeData="false" />
        </sharedListeners>-->

        <trace autoflush="false" indentsize="4">
          <listeners>
              <add name="FileLog" type="System.Diagnostics.TextWriterTraceListener" traceOutputOptions="DateTime" initializeData="felix.log"/>
              <add name="console" type="System.Diagnostics.ConsoleTraceListener" initializeData="false"/>
              <remove name="Default"/>
          </listeners>
        </trace>

    </system.diagnostics>
[...]

Then in code I call trace like this:

Public Shared Sub HandleException(ByVal ex As Exception)
   Trace.WriteLine(ex.Message, "Error")

[...]

There's something I'm missing I think. How do I say to the Trace method the right switch to use?? How can my application users change the config file to allow for tracing or disable it?

Thanks.

Narvik

Answer 1

You seem to be mixing the concept of logging/tracing via Trace.Write and Trace.WriteLine with logging/tracing using TraceSource objects.

TraceSource objects allow you to have individually controllable (via switches) "logging objects" such that you can turn logging on for some of your code and off for other parts of your code. The output from TraceSource objects can be configured to go to different TraceListeners (or to the same TraceListener). Trace.WriteLine is not really very flexible. It can be configured with only one level (i.e. globally you can log at Debug or Info or whatever), whereas with TraceSources, one TraceSource could be logging at Debug and another one could be logging at Info while another one could be completely Off.

See my answers in these links for some examples of how to configure TraceSources and how to use them in code.

How to use TraceSource across classes

Turning tracing off via app.config

What's the best approach to logging?

Add Trace methods to System.Diagnostics.TraceListener

Regarding how you want your tracing/logging to work in debug vs release, you can have two different app.config files. Both would define the same TraceSources (i.e. the same set of "named" tracing/logging objects). In the app.config to be used with debug builds, you might set the tracing/logging level to one value Debug/Info/Whatever and you might direct the output to the Console and/or a File and/or whatever. In the app.config to be used with debug builds, you might set the tracing/logging level to a different value (or Off)a nd direct the output to a File.

In both of the posts above I include several other links to information on System.Diagnostics, including the Ukadc.Diagnostics project. This project provides a very interesting formatting capability for use with System.Diagnostics based TraceListeners (provided the listeners come from Ukadc.Diagnostics) with NO changes in your actual tracing/logging statements. The formatting capability is similar to that provided by log4net and NLog.

Read the information that I linked above and see if it helps. Try using TraceSources rather than just Trace.WriteLine. When you are comfortable with that, maybe look into Ukadc.Diagnostics.

Wont

Thank you very much, I've read everything, you shed a light in my logging darkness :) I'd suggest you write an article/blog post/web page, whatever to concentrate all this information that would otherwise be spread. If you do, then send me the link! Thanks again. – Narvik

I finally figured it out, but still can't get the use of the id to pass to the TraceEvent method. If the trace source lets me configure where (listeners) and how much (switches) to log, and then I programmatically specify the event type (TraceEventType), what's the use of having to specify an Id too? – Narvik

For one idea about event ids, see the first answer to this question: https://mcmap.net/q/93719/-logging-best-practices-closed Look under "Other recommendations". Following that suggestion, you could categorize every log message (regardless of the TraceSource, TraceEventType, or the message). It would then be relatively easy to query/search your output for certain kinds of message. For example, if event id 1001 means "reading from file" and 1002 means "writing to file", you could find all log messages in your output that correspond to reading from or writing to a file. – Wont

You might have file access in many places in your code and if you had not tagged your messages with the event id, it might be difficult to determine from the tracing/logging output where you had file access. Having the event id as a column (if you are tracing/logging to a database) would also give you one more column to query on when analyzing your tracing/logging output. If your event ids are documented, then a user with problem could turn on tracing/logging and might see that there are a lot of 5001 and 5002 event ids. That might mean something to you without even having to ... – Wont

Look in greater detail at the logfile. How (or if) you use event id is up to you. Used correctly, it could probably help a lot in analyzing logging out and troubleshooting. Hope this helped. – Wont