Question

我有一组WCF服务，到目前为止我一直在使用ASP.NET MVC应用程序。当服务器发现客户端提交的内容有问题时，这些服务操作会返回FaultException。例如：

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

这在我的ASP.NET应用程序中非常有用

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

然而，对于Silverlight，这一切都失败了。服务器返回带有faultexception的500状态代码（如预期的那样），但是对于Silverlight，这看起来就像是一个duff响应。

以下MS文章指出（丑陋）解决此问题：http://msdn.microsoft.com/en-us/library/ee844556%28v=vs.95%29.aspx 此解决方法使服务传输200状态代码，即使存在FaultException，以便Silverlight客户端可以获取它们。但这会破坏我服务的“普通”客户端（我的ASP.NET应用程序，其他用户）。

但是，服务的重点是要与客户分开。我仍然希望我的服务返回500个状态代码，以便我的ASP.NET应用程序可以检测到FaultExceptions并处理它们。但我也希望Silverlight能够处理它们。

以前有人反对这个吗？

Answer 1

我们正在使用丑陋的500到200转换器端点行为（您提供的链接中的一个选项），它在Silverlight中非常适用。一个快速的Windows窗体客户端似乎也明白，虽然响应代码是200（ok），我仍然看到e.Error正确填充。对于您正在使用的客户端（ASP.NET），是否存在200与500的任何技术问题？如果没有，问题是什么？

直到最近，我还在Silverlight中使用了备用HTTP堆栈（该MSDN文章中的其他选项）。使用它修复了很多东西（如果我没记错的话，包括错误返回）。我们使用它，因为无论浏览器如何，它都提供了一致的NTLM / Negotiate身份验证。我不得不停止使用它，因为决定缺少HTTP压缩是一个交易破坏者。这将使服务保持不变（错误时间为500秒）。

Silverlight 4和ASP.NET的WCF故障异常

1 个答案: