IncludeExceptionDetailInFaults не ведет себя так, как думал

Question

У меня есть этот простой тестовый проект, чтобы проверить поведение IncludeExceptionDetailInFaults.

    public class Service1 : IService1
    {
        public string GetData(int value)
        {
            throw new InvalidCastException("test");
            return string.Format("You entered: {0}", value);
        }
    }

    [ServiceContract]
    public interface IService1
    {
        [OperationContract]
        string GetData(int value);
    }

В app.config службы мне присвоено значение true

 <serviceDebug includeExceptionDetailInFaults="True" />

На стороне клиента:

            try
            {
                using (var proxy = new ServiceReference1.Service1Client())
                    Console.WriteLine(proxy.GetData(5));
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }

Вот что я думал о поведении: Установка параметра includeExceptionDetailInFaults = true будет распространять подробности исключения клиенту. Но я всегда получаю сообщение CommunicationObjectFaultException.

Я попытался использовать FaultContract (typeof (InvalidCastException)) в контракте, но с тем же поведением, получая только CommunicationObjectFaultException.

Единственный способ заставить его работать - это выдать новое FaultException (new InvalidCastException ("test"));

Но я подумал, что с IncludeExceptionDetailInFaults = true выше было сделано автоматически.

Я что-то упустил?

Answer 1

Это потому, что вы поместили сервисный клиент в блок using.

WCF-клиенты - это единственное место в .NET, где вы не должны использовать using, потому что это замаскирует «реальное» исключение.

Техническое объяснение: Dispose вызывает Close, который всегда выдает CommunicationObjectFaultedException, если канал уже неисправен (то есть в результате предыдущего исключения), который впоследствии ставит это исключение на вершине стека. При очистке ICommunicationObject во избежание маскировки исключения сначала необходимо проверить State, чтобы выяснить, не было ли оно неисправным, и, если это так, вызвать Abort вместо Close.