Silverlight doesn’t handle WCF problems very well – it is a known fact.
One of solutions to this limitation is to use debugging proxy tools such as Fiddler2.
Another, more advanced option that we have is to enable logging on a WCF end.
Because logging happens on a server where WCF is hosted, we (obviously) need access to this server so this mechanism will not fit all scenarios.
Logging can be enabled by modifying web.config file:

   1: <system.diagnostics>       

   2:     <sharedListeners>   

   3:       <add name="WcfListener"   

   4:               type="System.Diagnostics.XmlWriterTraceListener"   

   5:               initializeData="c:\logs\wcfLog.svclog"  />   

   6:     </sharedListeners>       

   7:     <sources>         

   8:       <!-- switchValue attribute has no impact on MessageLogging -->   

   9:       <source name="System.ServiceModel.MessageLogging">  

  10:          <listeners>  

  11:            <add name="WcfListener" />  

  12:          </listeners>  

  13:        </source>        

  14:        <source name="System.ServiceModel"  

  15:                      switchValue="Warning, ActivityTracing"  

  16:                      propagateActivity="true" >  

  17:          <listeners>  

  18:            <add name="WcfListener" />  

  19:          </listeners>  

  20:        </source>        

  21:      </sources>      

  22:  </system.diagnostics>  

  23:     

  24:     

  25:  <system.serviceModel>  

  26:    <diagnostics>  

  27:      <messageLogging   

  28:           logEntireMessage="true"   

  29:           logMalformedMessages="false"  

  30:           logMessagesAtServiceLevel="true"   

  31:           logMessagesAtTransportLevel="false"  

  32:           maxMessagesToLog="3000"  

  33:           maxSizeOfMessageToLog="2000"/>  

  34:    </diagnostics>  

  35: </system.serviceModel>

Any issues with WCF services will be logged to c:\logs\wcfLog.svclog file that can be viewed using Service Trace Viewer Tool which gives us lots of valuable information presented in nice graphical way.

Playground

Let’s create a test service and pass very long string to it to exceed reader quota limit:

   1: StringBuilder sb = new StringBuilder();   

   2:      

   3: for (int i = 0; i < 10000; i++)    

   4:     sb.Append("!");   

   5:  

   6: ReaderQuotaClient.DoWorkAsync(sb.ToString());

This will result in well know ‘The remote server returned an error: NotFound‘ communication exception.

Usually we would use Fiddler2 to debug the service call and see what’s going on (as described here), but in this case we’ll have a look at log files instead.

We double click the trace file to bring Service Trace Viewer:

Red color indicates problems and we can see that something went wrong when processing DoWork method:

Clicking ‘Throwing an Exception’ log entry will give us more insight into the orgin of the problem

We can achieve the same effect with Fiddler2, but using logs and Service Trace Viewer gives us a lot more information about internal workings of our services.

We can for example use graph of service activity to help us to understand which part of service needs performance improvement.

For more info on WCF Debugging and Logging see these msdn articles:

• Configuring Message Logging
• Recommended Settings for Tracing and Message
• Activity Tracing and Propagation for End-To-End Trace Correlation
• Service Trace Viewer Tool
  
  

Test project can be downloaded from here.

• Previous Entry: WCF Security – SSL and Man-In-The-Middle Attacks
• Next Entry: Book: Crossing The Chasm (Technology Adoption Lifecycle)