使用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故障異常

回答

相關問題