WCF Error Exceptions with Silverlight 4 and ASP.NET

Question

I have a set of WCF services that I used with an ASP.NET MVC application. These utility operations throw a FaultException when the server has identified a problem with what the client has sent. For instance:

if(string.IsNullOrEmpty(request.Name)) throw new FaultException<ValidationDictionary>(new ValidationDictionary()); 

This works fine in my ASP.NET application

 catch(FaultException<ValidationDictionary> fault) { // Happy error handling. } 

However, with Silverlight, all this fails. The server returns a 500 status code with an error (as expected), but for Silverlight it looks like a duff response.

The following MS article points out (ugly) work for this: http://msdn.microsoft.com/en-us/library/ee844556%28v=vs.95%29.aspx This workaround causes the service to send 200 status codes, even if a FaultException exists, so the Silverlight client can get them. But this will ruin the "normal" clients of my service (my ASP.NET application, other users in the wild).

However, the service point is the separation of your customers. I still want my services to return 500 status codes so that my ASP.NET application detects FaultExceptions errors and processes them. But I also want Silverlight to be able to handle them.

Has anyone come across this before?

Answer 1

We use the ugly behavior of the endpoint from 500 to 200 (one of the options in the link you provided), it works fine in Silverlight. The Windows Forms fast client also understands that while the response codes are 200 (ok), I still see that e.Error is filled in correctly. Are there any technical issues with 200 vs 500 with the clients you are using (ASP.NET)? If not, then what is the problem?

I also used an alternate HTTP stack in Silverlight (other parameters in this MSDN article) until recently. Using this, a lot of things were fixed (including the error returned if I remember correctly). We used it because it provided consistent NTLM / Negotiate authentication regardless of browser. I had to stop using it, as it was decided that the lack of HTTP compression was a transaction violation. This will keep the service unchanged (500 s on errors).