WCF traces are very helpful in diagnosing and debugging problems with a deployed WCF service. This post describes how traces generated by a WCF RIA service can be accessed and inspected directly from a web browser in a variety of formats.

WCF traces capture information about the lifetime of a WCF service as well as processing stages for every message. Traces provide much richer information about the inner workings of a WCF service compared to any diagnostic information that may be sent back to the client in the form of SOAP faults or transport specific error codes (e.g. HTTP status codes). In particular, issues related to message processing within the WCF channel stack rarely result in useful diagnostic information propagated back to the client; at the same time, WCF traces usually provide adequate information to diagnose the problem.

WCF traces are collected and captured using the System.Diagnostics infrastructure. In a typical use case one would configure the system to collect the WCF traces in a file on the server. This approach is oftentimes suboptimal for WCF services deployed in shared hosting environments, since access to the file system may be restricted.

Accessing WCF RIA service traces from a web browser

One approach to provide easy access to WCF RIA service traces for debugging and diagnostic purposes is to collect the trace information in memory instead of the file system and expose this information directly over a new service endpoint. WCF RIA Services Toolkit April 2010 supplies a custom implementation of an endpoint factory for WCF RIA services which exposes WCF traces collected within an application domain using a WCF REST endpoint in three formats: ATOM, XML, and HTML.

The feature can be enabled by referencing Microsoft.ServiceModel.DomainServices.Hosting.dll from the WCF RIA Services Toolkit in the web application (make sure to mark the library reference “copy local”) and adding the highlighted sections to the the web.config file (other pre-existing sections omitted for brevity):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<configuration>       
  <system.diagnostics>         
    <sources>          
 <source name="System.ServiceModel" switchValue="Information" propagateActivity="false">          
   <listeners>          
     <add name="InMemoryTraceListener" />          
   </listeners>          
 </source>          
    </sources>          
    <sharedListeners>          
 <add    
       type="Microsoft.ServiceModel.DomainServices.Hosting.InMemoryTraceListener, Microsoft.ServiceModel.DomainServices.Hosting"           
       name="InMemoryTraceListener" />          
    </sharedListeners>          
  </system.diagnostics>     

  <system.serviceModel>       
    <domainServices>         
 <endpoints>          
   <add           
               name="traces"           
               type="Microsoft.ServiceModel.DomainServices.Hosting.TracingDomainServiceEndpointFactory, Microsoft.ServiceModel.DomainServices.Hosting"           
               maxEntries="200"/>          
 </endpoints>          
    </domainServices>        
  </system.serviceModel>        
</configuration>

After the service is deployed, traces for all WCF services running in the application domain will be collected in memory and can be accessed from the web browser by navigating to a URL formed by appending “/traces” to the URL of any of the WCF RIA services running in the web application. For example, if the web application containing a WCF RIA service created using the Business Application project template is deployed in the “abc” virtual directory on localhost, and the project namespace is “MyCompany.MyProject”, then WCF traces can be accessed by navigating to:

1
http://localhost/abc/MyCompany-MyProject-AuthenticationService.svc/traces

(The “MyCompany-MyProject-AuthenticationService.svc” can be replaced with a reference to any of the WCF RIA service endpoints in the web application).

If no URL parameters are specified, traces will be returned in the ATOM format.

Note that Internet Explorer version 7 and greater provides a very usable interface for viewing, sorting, and searching through an ATOM feed. By entering “error” in the provided search box one can very quickly locate exception traces.

Other formats can be explicitly requested by specifying a URL parameter, for example:

1
2
3
http://localhost/abc/MyCompany-MyProject-AuthenticationService.svc/traces?format=atom
http://localhost/abc/MyCompany-MyProject-AuthenticationService.svc/traces?format=xml
http://localhost/abc/MyCompany-MyProject-AuthenticationService.svc/traces?format=html

Given that traces are collected in memory, a quota is provided to limit the maximum number of most recent traces that will be kept. By default 200 most recent traces are maintained, but the value can be modified using the “maxEntries” attribute in the configuration file:

1
2
3
4
5
6
7
8
<domainServices>    
 <endpoints>    
   <add     
               name="traces"     
               type="Microsoft.ServiceModel.DomainServices.Hosting.TracingDomainServiceEndpointFactory, Microsoft.ServiceModel.DomainServices.Hosting"     
maxEntries="200"/>    
 </endpoints>    
    </domainServices>

Tracing information should only be exposed for access by web clients in controlled development or staging environments for the same reasons one should not propagate all ASP.NET exceptions back to the client in a production deployment.