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

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

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也能够处理它们。

有没有人反对过这个？

来源

2011-04-01 James

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

直到最近，我还使用Silverlight中的备用HTTP堆栈（该MSDN文章中的其他选项）。使用这个固定了很多东西（包括错误，如果我记得正确）。我们使用它，因为它提供了一致的NTLM /协商身份验证，无论浏览器如何。我不得不停止使用它，因为它决定缺乏HTTP压缩是一个破坏行为。这将保持服务不变（错误500秒）。

来源

2011-04-01 13:12:33 Aardvark

我不想改变结果代码，因为它看起来像一个非常丑陋的黑客，并会混淆服务的其他用户。我无法确定HTTP堆栈选项，因为我正在使用Message Transport安全性，并认为这可能会导致问题。压缩问题对我来说可能不是什么大问题，但它很烦人。我会尝试解决方案，看看我得到多远。谢谢。 – James 2011-04-01 13:51:56

在我们的案例中，安全性在备用堆栈中工作得更好。我宁愿坚持下去，但我们所交谈的其中一个Web服务将大量数据发回给我们。当HTTP压缩为他们做“免费”时，他们不愿意自己优化数据。你必须选择你的战斗... – Aardvark 2011-04-01 13:59:26

这工作正常，感谢您的输入。 – James 2011-04-05 20:05:15

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

回答

相关问题