Exceptions de pannes WCF avec Silverlight 4 et ASP.NET

Question

J'ai un ensemble de services WCF que j'utilisais avec une application ASP.NET MVC jusqu'à présent. Ces opérations de service retournent une exception FaultException lorsque le serveur a identifié un problème avec ce que le client a soumis. Par exemple:

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

Cela fonctionne très bien dans mon application ASP.NET

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

Cependant, avec Silverlight tout cela échoue. Le serveur retourne un code d'état de 500 avec la faultexception (comme prévu) mais pour Silverlight cela ressemble à une simple réponse.

L'article MS suivant indique un (laid) travail autour de ceci: http://msdn.microsoft.com/en-us/library/ee844556%28v=vs.95%29.aspx Cette solution rend le service de transmission de 200 codes d'état, même s'il y a un FaultException, de sorte que le client Silverlight peut les obtenir. Mais cela gâchera les clients 'normaux' de mon service (mon application ASP.NET, d'autres utilisateurs dans la nature).

Cependant, le point de service est d'avoir une séparation de vos clients. Je veux toujours que mes services renvoient 500 codes d'état afin que mon application ASP.NET puisse détecter les exceptions FaultException et les gérer. Mais je veux aussi que Silverlight soit capable de les gérer aussi.

Quelqu'un a-t-il déjà comparé cela?

Answer 1

Nous utilisons le mauvais comportement du point de terminaison du convertisseur 500 à 200 (l'une des options du lien que vous avez fourni), cela marche plutôt bien dans Silverlight. Un client Windows formulaire rapide semble également comprendre que, bien que les codes de réponse sont 200 (ok), je vois toujours e.Error correctement. Y at-il vraiment des problèmes techniques avec 200 contre 500 avec les clients que vous utilisez (ASP.NET)? Si non, quel est le problème?

J'ai également utilisé la pile HTTP alternative dans Silverlight (les autres options de cet article MSDN) jusqu'à récemment. L'utilisation de ce qui fixe beaucoup de choses (y compris l'erreur de retour si je me souviens bien). Nous l'utilisions car il fournissait une authentification NTLM/Negotiate cohérente quel que soit le navigateur. J'ai dû arrêter de l'utiliser car il a été décidé que le manque de compression HTTP était un briseur d'affaire. Cela garderait le service inchangé (500s sur les erreurs).