Adventures with Silverlight and WCF - The remote server returned an error: NotFound

By Doug Holland (Intel) (249 posts) on February 3, 2010 at 12:12 am

While architecting and developing CodePlex.Diagnostics 4.0, the first version of the exception and logging framework to support Silverlight, I have had some considerable headaches debugging issues related to service communication and Silverlight 3 applications.

Another interesting aspect of the transition from writing standard .net based code to that based upon Silverlight 3 is the difference between the types found within the standard BCL, or Base Class Library, and the SCL, or Silverlight Class Library.

We'll begin tonight by describing an exception that you might encounter while writing Silverlight 3 applications that communicate with a remote WCF service, the text of the exception indicates that "The remote server returned an error: NotFound". What was not found? Unfortunately the exception message fails to communicate that small piece of information that could be so useful.

Initially I had thought the issue was related to cross domain communication restrictions imposed upon Silverlight 3 applications although this thought was quickly dismissed after verifying the existence of the clientaccesspolicy.xml file using HttpDebugger Pro. While I would recommend using HttpDebugger Pro, the free Http debugger Fiddler can also be used for this verification.

WCF tracing fortunately enabled me to discover what exactly had not been found, and therefore caused the exception message, "The remote server returned an error: NotFound", that was before attempting to ruin my evening. In order to enable WCF tracing, simply add the following configuration Xml to the service that you are attempting to connect to from the Silverlight 3 application, or any other client for that matter. Obviously substitute an appropriate filename and path for the .svclog file.

 <configuration>
   <system.diagnostics>
      <sources>
            <source name="System.ServiceModel"
                    switchValue="Information, ActivityTracing"
                    propagateActivity="true">
            <listeners>
               <add name="traceListener"
                   type="System.Diagnostics.XmlWriterTraceListener"
                   initializeData= "c:\CodePlex.Diagnostics\CodePlex.Diagnostics.Services.Web.svclog" />
            </listeners>
         </source>
      </sources>
   </system.diagnostics>
</configuration>

When opening the resulting trace within the Microsoft Service Trace Viewer it should be immediately apparent if there are any exceptions that will provide the additional information you will need to resolve the communication issue at hand. With the exception that I was debugging the trace immediately showed an issue within the tree on the left hand side of the viewer and after investigating further the issue was caused, in this instance, by the fact that there was a type mismatch between a data member within a data contract that existed upon the server within a standard .net library and on the client within a Silverlight 3 library. Issue discovered, resolved, and unit tested. I have also included a figure showing the HttpDebugger Pro and the verification that the clientaccesspolicy.xml file was appropriately installed upon the Web server.

Silverlight 3, and the forthcoming Silverlight 4, are very interesting technologies to build some fantastic user experiences and in fairness this issue eventually had more to do with the Windows Communication Foundation than Silverlight. Hopefully this blog post will help someone resolve an exception in WCF sometime in the future.

Categories: Parallel Programming, Software Tools

For more complete information about compiler optimizations, see our Optimization Notice.

Comments (5)

February 3, 2010 1:23 AM PST


Felix Kollmann		 There is an even easier way to pass the "correct" exceptions to Silverlight:

http://msdn.microsoft.com/en-us/library/dd470096(VS.96).aspx

Greetz Felix
February 3, 2010 11:45 AM PST

Doug Holland (Intel)
Doug Holland (Intel)Total Points:
14,135
Black Belt
 Hey Felix,

Without a doubt the use of SOAP faults is the way exceptions should be communicated from a service tier to Silverlight application although often much of the low-level detail of the exception is not communicated to the client because it would serve little use within the client unless a developer is debugging the client at the time.

What the application that was being debugged is designed to do is actually to pass exceptions, that occur internally within a given Silverlight application, to a WCF service that will persist those exceptions within a database such that a developer can investigate those exceptions at a later time.

Regards,

Doug
February 7, 2010 11:16 PM PST

Doug Holland (Intel)
Doug Holland (Intel)Total Points:
14,135
Black Belt
 Hey Felix,

After taking another look at the MSDN page you referred me to above, I have now implemented the SilverlightFaultBehavior into the CodePlex.Diagnostics service tier.

Thanks again,

- Doug
May 16, 2011 12:02 PM PDT


Doug Squires		 Thanks. Helpful.
August 13, 2011 10:27 AM PDT


yogs		 Thank you, thank you! I've been fighting with a WCF MaxReceivedMessageSize issue on the binding, while I had set everything else to larger sizes in the readerQuotas, this little attribute of the binding itself was not mentioned until I did the trace. Finally, I can move forward!

Trackbacks (7)


Leave a comment  

To obtain technical support, please go to Software Support.
Name (required)*

Email (required; will not be displayed on this page)*

Your URL (optional)


Comment*