C# IncludeExceptionDetails结果的行为与预期不同

我有这个简单的测试项目只是为了测试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" />

这就是我所认为的行为： 设置为includeExceptionDetailInFaults=true会将异常详细信息传播到客户端。但我总是得到沟通对象的错误例外

我确实尝试在合同上使用FaultContract（typeof（InvalidCastException）），但行为相同，只得到了CommunicationObjectFaultException

使其工作的唯一方法是抛出新的FaultException（新的InvalidCastException（“test”）

但我认为，使用IncludeExceptionDetailInFaults=true，上述操作是自动完成的

---

我错过什么了吗

这是因为您使用块将服务客户端放入了一个

块中

WCF客户端是.NET中唯一一个您可以访问的地方，因为它将屏蔽“真正”的异常

技术说明：
Dispose
调用
Close
，如果通道已经出现故障（即由于以前的异常），它将始终抛出
通信对象故障异常
，随后将该异常置于堆栈顶部。清理
ICommunicationObject
时，为了避免掩盖异常，您必须首先检查
状态
以查看它是否有故障，如果有故障，请调用
中止
，而不是
关闭
谢谢！当通道出现故障时，Close如何导致CommunicationObject FaultException？@pdiddy:
CommunicationObject.Close
被编程为在通道出现故障时引发异常。这不是偶然的。它不能检查状态并在通道出现故障时中止吗？只是想知道为什么它是这样实现的。@pdiddy:它确实检查状态，并且它确实调用了
Abort
。。。然后它抛出一个异常。我确信它可以做很多其他的事情，但这是WCF团队选择的实现它的方式，对许多人不利。现在甚至在MSDN上有记录：
            try
            {
                using (var proxy = new ServiceReference1.Service1Client())
                    Console.WriteLine(proxy.GetData(5));
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }