0 comments
.NET 
Silverlight has limited support for webservices, for example you only have the basic http binding for soap based services. This is however not the only limitation that comes with silverlight. It is also impossible to see the exact SOAP error inside silverlight when your service drops out for some reason. Instead of the actual fault you will get either a HTTP 404 error for ASP.NET application services or a HTTP 500 error in case of normal WCF services.
Fiddler to the rescue
Since most webservices throw soap faults you will need a way to capture those somewhere. The only way to do this, is to use a HTTP sniffer that captures the http response containing the soap message that is send back to the silverlight application. Fiddler is great tool that allows you to capture all HTTP traffic in internet explorer and firefox. It also helps to detect problems with the crossdomain policy in silverlight.
Should silverlight actually throw exceptions?
This question came to mind when I was trying hard to discover why my service kept returning 404 – not found errors to silverlight. It is not very friendly to a user to just display that the service could not be found when there is actually something really different going on.
The alternative to these unfriendly HTTP errorcodes is to extend the contract of the service, so that it returns result objects that contain the result of the operation, but also contain error information if the operation failed. That way you will have a better way of showing errors in the GUI. It will also help to keep the HTTP error codes for really bad situations 😉