Исключения сбоев WCF в Silverlight 4 и ASP.NET

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 это все не удается. Сервер возвращает код состояния 500 с ошибкой (как и ожидалось), но для Silverlight это выглядит просто как невнятный ответ.

В следующей статье MS указывается (некрасивый) обходной путь для этого: http://msdn.microsoft.com/en-us/library/ee844556%28v=vs.95%29.aspx Этот обходной путь заставляет службу передавать 200 кодов состояния, даже если есть исключение FaultException, чтобы клиент Silverlight мог их получить. Но это испортит «нормальных» клиентов моего сервиса (мое приложение ASP.NET, другие пользователи на свободе).

Тем не менее, суть услуг заключается в том, чтобы отделиться от ваших клиентов. Я все еще хочу, чтобы мои службы возвращали 500 кодов состояния, чтобы мое приложение ASP.NET могло обнаруживать исключения FaultException и обрабатывать их. Но я также хочу, чтобы Silverlight мог справиться и с ними.

Кто-нибудь сталкивался с этим раньше?

Answer 1

Мы используем уродливое поведение конечной точки конвертера от 500 до 200 (один из вариантов в предоставленной вами ссылке), оно прекрасно работает в Silverlight.Быстрый клиент формы окна, кажется, также понимает, что, хотя коды ответов равны 200 (хорошо), я все еще вижу, что e.Error заполняется правильно.Есть ли какие-либо технические проблемы с 200 против 500 с клиентами, которые вы используете (ASP.NET)?Если нет, то в чем проблема?

Я также использовал альтернативный стек HTTP в Silverlight (другие опции в этой статье MSDN) до недавнего времени.Использование этого исправило много вещей (включая ошибку, возвращающуюся, если я правильно помню).Мы использовали его, поскольку он обеспечивал согласованную аутентификацию NTLM / Negotiate независимо от браузера.Мне пришлось прекратить использовать его, так как было решено, что отсутствие сжатия HTTP является преградой.Это позволит сохранить службу без изменений (500 с при ошибках).