Can't figure out .net 2010 trace and app.config

Question

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

I want the debug trace to be output to the console, and the release to the log file only.

I ', ve wrote 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 the code I call the trace as follows:

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

[...]

Something is missing for me there, I think. How do I tell the Trace method the correct switch to use? How can application users modify the configuration file so that it can be monitored or disabled?

Thanks.

Answer 1

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

TraceSource objects allow you to have “logging objects” individually managed (via switches), so you can enable logging for some code and disable it for other parts of your code. The output of TraceSource objects can be configured to go to different TraceListeners (or also TraceListener). Trace.WriteLine is not very flexible. It can only be configured at one level (i.e. globally you can log into Debug or Info or something else), while with TraceSources one TraceSource can be registered in Debug, and the other can be registered in Info, and the other can be completely disconnected.

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 for classes

Disabling tracing through app.config

What is the best way to log?

Add trace methods to System.Diagnostics.TraceListener

Regarding how you want your trace / logging to work in debug vs release, you can have two different app.config files. Both will define the same TraceSources (i.e., the same set of "named" trace / registration objects). In app.config, which will be used with debug builds, you can set the trace / logging level to one value of Debug / Info / Whatever, and you can direct the output to the console and / or to a file and / or something else. In app.config, which will be used with debug builds, you can set the trace / logging level to a different value (or off), and the direct output to the file.

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

Read the information I linked above and see if it helps. Try using TraceSources, not just Trace.WriteLine. When you are comfortable, maybe take a look at Ukadc.Diagnostics.