After deploying application a proper troubleshooting policy should be ready in order to perform maintenance activity of our project life cycle. Here we will see different tools available from Microsoft within visual studio in order to manage, configure, debug and troubleshoot WCF service after deployment. Note that if you are unfamiliar with WCF, please read my WCF Tutorial .
WCF Tracing can track all the events or only specified events in the program. Tracing is built upon the System.Diagnostics namespace of the .NET Framework. The Debug and Trace classes under this namespace are responsible for debugging and tracing purpose.
Tracing is turned off by default and needs to be enabled to start using tracing. We can enable tracing by two ways. One is through code and another is from config file. Enabling tracing in configuration is the optimal method since we can easily turn it on and off as required. When debugging is no longer required we should turn tracing enable off.
Enabling Tracing
The following code snippet will enable tracing through configuration file:
<system.diagnostics> <trace autoflush="true" /> <sources> <source name="System.ServiceModel" switchValue="All"> <listeners> <add name="TraceListeners" type="System.Diagnostics.XmlWriterTraceListener" initializeData= "c:\Log\trace.svclog"/> </listeners> </source> </sources> </system.diagnostics>
In this example, the name and type of the trace listener is specified. The Listener is named TraceListeners and the standard .NET Framework trace listener (the native format for the tool - System.Diagnostics.XmlWriterTraceListener) is added as the type. The initializeData attribute is used to set the name of the log file for that Listener. Here the fully qualified file name is used as “c:\Log\trace.svclog”.
Tracing Levels:
Tracing Levels:
The tracing level is controlled by the switchValue setting. The available tracing levels are described below:
|
SL. No |
Level |
Tracked Events |
Content of the Tracked Events |
|
1. |
Off |
No traces are emitted.
|
|
|
2. |
Critical |
Out of memory exception, Stack overflow exception, Application start |
|
|
3. |
Error |
All exception are logged |
Unexpected processing has happened. The application was not able to |
|
4. |
Warnings |
Timeout exceeded, Credential rejected, throttling exceeded, receiving |
A possible problem has occurred or may occur, but the application |
|
5. |
Information |
Channels and endpoints created, message enters/leaves transport, configuration |
Important and successful milestones of application execution, |
|
6. |
Verbose |
Debugging or application optimization |
Low level events for both user code and servicing are emitted. |
|
7. |
Activity Tracing |
Tracing for transfers, activity boundaries, start/stop |
Flow events between processing activities and components. |
|
8. |
All |
All listed events |
Application may function properly. All events are emitted. |
Trace Sources:
WCF defines a trace source for every assembly. Traces generated within an assembly are accessed by the listeners which are defined for that source. The below trace sources are defined:
- System.ServiceModel: Logs all stages of WCF processing, whenever the configuration is read, a message is processed in transport, security processing, a message is dispatched in user code, and so on.
- System.ServiceModel.MessageLogging: Logs all messages that flow through the system.
- System.IdentityModel: Logs data for authentication and authorization.
- System.ServiceModel.Activation: Logs the activity of creating and managing service hosts.
- System.IO.Log: Logging for the .NET Framework interface to the Common Log File System (CLFS).
- System.Runtime.Serialization: Logs when objects are read or written.
- CardSpace: Logs messages related to any CardSpace identity processing that occurs within WCF context.
Continues…