Пользовательское исключение, создаваемое веб-службой, не рассматриваемой клиентом как один и тот же тип (с использованием общих сборок)
Я создал пользовательское исключение InvalidSessionException
. Однако при попытке поймать или оценить, является ли вызванное исключение такого типа, оно не работает. Это значит, что он оба EX is
и Catch Ex
, не оценивает в InvalidSessionException
try
{
acc = this.fda.GetAccountHeader(this.selectedTicket.AccountId);
}
catch (Exception ex)
{
if (ex is Enterprise.Data.InformationModel.CustomExceptions.InvalidSessionException)
{
this.lblError.Text = Resources.Resource.error_sessionedTimedOut;
this.MPError.Show();
}
return;
}
Я также пробовал (без каких-либо различий в результатах)
catch (Enterprise.Data.InformationModel.CustomExceptions.InvalidSessionException ex)
{
this.lblError.Text = Resources.Resource.error_sessionedTimedOut;
this.MPError.Show();
return;
}
catch (Exception ex)
{
return;
}
из того, что я могу сказать, исключение создается правильного типа.
Дополнительная Информация:
ex.GetType().FullName
= "System.ServiceModel.FaultException1[[System.ServiceModel.ExceptionDetail, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]"
повторное использование типов включено в службе?
2 ответов
кредит, где кредит должен
Nintey-девять процентов кредита этого ответа идет на комментарий, оставленный Репетти Адриано на этой странице. Я просто проверил это решение сам, поскольку у меня была та же самая проблема, что и описанная в вопросе выше.
Проблема
В ссылке на модальное окно "Настройка ссылки на службу"; просто потому, что вы выбираете " повторно использовать типы во всех ссылках сборки " не означает, что он действительно это сделает – это кажется ленивой операцией, и в основном эти ссылки будут сделаны, если код автоматической генерации происходит чтобы соответствовать его.
Решение
Поэтому, если вы на самом деле отметьте, что вас волнует, похоже, что он гарантированно будет использоваться вместо может быть. Это достигается путем изменения переключателя с "типы повторного использования во всех ссылочных сборках" на " повторное использование типы в указанных сборках" (второй переключатель).
Мои Вспомогательные Наблюдения
Похоже, что это особенно влияет на FaultExceptions, я не знаю почему, но это так. Мои FaultExceptions в моем проекте создавались в пространстве имен ссылки на службу вместо повторного использования их из ссылочной сборки.
Что особенно озадачивает, так это то, что namspace специально описывается, когда вы смотрите на Ссылка.ДКС код услуги. Тем не менее, он не работал, пока я не сделал то, что описал выше. Наконец, я просто хочу отметить, что это отличный пример "нарушения канона" или "не быть каноническим".
Я считаю, что вам нужно использовать строго типизированный FaultException<T>
. Что-то вроде того...
отказ от ответственности: следующий код не был протестирован
СЕРВЕР
[ServiceContract]
public interface ISampleService
{
[OperationContract]
[FaultContractAttribute(typeof(InvalidSessionException)]
void SampleMethod();
}
void SampleMethod()
{
...
throw new FaultException<InvalidSessionException>();
}
СТОРОНА КЛИЕНТА
...
try
{
_wcfChannel.SampleMethod();
catch (FaultException<InvalidSessionException> ex)
{
// take appropriate action
}
}
ДОПОЛНИТЕЛЬНОЕ ЧТЕНИЕ
- MSDN:FaultException
- remondo.net: использование исключений ошибок типа WCF (простой пример)
- iDesign:WCF контракт неисправности (пример кода)
- CodeProject: учебник для начинающих Для понимания обработки исключений, FaultExceptions и FaultContracts в WCF