WPF内置配置常用

WPF内置配置常用

我们做WPF项目时往往有时候会因为项目里的内置配置满足不了项目需求而报错，比如我们访问服务时间过长会自动断开连接；我们提交数据过大时会报错；如下图：

当使用客户端调取的数据过多时，会出现这个异常Request Entity Too Large。
一般情况下，系统默认值是65536字节，大约容纳100-200条左右的数据。
所以建议您在您的项目中，为了避免使用时期出现这个错误。您应该使用如下解决方案。
需在服务端的Service下面的Web.config绑定好配置先，
MaxReceivedMessageSize：获取或设置配置了此绑定的通道上可以接收的消息的最大大小。
MaxBufferSize：获取或设置缓冲区的最大大小，该缓冲区用于接收来自通道的消息。
需要把MaxReceivedMessageSize改成最大值2147483647和MaxBufferSize也改为最大值2147483647

服务端修改好后还要到客户端修改，客户端的配置项是App.config，里面的修改如图所示

跟服务端修改配置一样，客户端在system.serviceModel下面添加binding绑定同样地把MaxReceivedMessageSize改成最大值2147483647和MaxBufferSize也改为最大值2147483647。
另外还有一涉及一些其他配置和说明如下：
1.OpenTimeout
客户端与服务端建立连接时，如果超过指定时间都还没完成，就引发TimeoutException。
在TCP通讯中，服务器必须首先准备好侦听端口并在该端口上侦听(Listen)，而客户端则必须首先向服务器发出连接(Connect)指令，
服务器端收到后作出接受响应(Accept)后连接成功，此后两者就可以互发消息了。
在WCF领域中，类似地，Open()表示建立一个Binding。
测试：拨网线。
2.CloseTimeout
与OpenTimeout类似, CloseTimeout用于关闭一个连接时。
一般情况下，客户端比较随意，不会在意这个超时异常。“Close()是我发出的，我自己决定何时清理资源。”
在服务器就不同了，她必须对客户端负责，不能乱来，在收到Close()成功的响应之前，或收到超时异常之前，不能随意清理与客户端相关的资源。
3.SendTimeout
客户端调用的超时，默认1分钟。每次调用都必须在指定时间内完成，否则将引发TimeoutException。
在TCP通讯中，双方建立连接后，客户端如果需要发送消息给服务端，就发送一个数据包给服务器，服务器收到后必须给出一个响应，客户端收到这个响应后才能宣告发送成功。类似地，服务器也可能主动发送消息给客户端。这两个动作，分别对于客户端和服务器来说，都是发送(Send)，而对于另一方来说都是接收(Receive)。
但是，在WCF领域中的SendTimeout中的Send与TCP的Send理念上类似，但是实质上完全不是一回事。SendTimeout中的Send是指客户端发起调用。
在WCF客户端，用proxy.InnerChannel.OperationTimeout可以取到SendTimeout的值。（此处，proxy 是自动生成的服务代理类XxxClient的一个实例）
测试：在服务器的调用处理代码中插入MessageBox.Show(…)或Thread.Sleep(…)。
4.ReceiveTimeout
与SendTimeout同理, ReceiveTimeout中的Receive是指服务器端发起回调(Callback)。只有在双向通讯绑定时适用，如WSDualHttpBinding, NetTcpBinding, NetNamedPipeBinding, …
ReceiveTimeout是服务器回调(Callback)的超时，默认10分钟。每次回调都必须在指定时间内完成，否则将在服务器端引发TimeoutException。
测试：在客户端的回调处理代码中插入MessageBox.Show(…)或Thread.Sleep(…)。–>
(1)ReceiveTimeout 属性：确定 Read 方法在能够接收数据之前保持阻塞状态的时间量。这一时间的度量单位为毫秒。
如果超时在 Read 成功完成之前到期，TcpClient 将引发 SocketException。默认为无超时。
在通讯过程中,由于客户端是周期性地向服务器请求数据，若客户端的请求指令或是服务端发来的数据包丢失的话，那么客户端将一直等待，陷入假死状态。
由于默认为无超时,所以一定要记得设定客户端接收的超时时间，若服务器端无相应，客户端应该抛出异常，而不是毫无意义的等待。