WCF-003:关于 WCF 基础连接已经关闭 连接被意外关闭-序列化问题
2013-10-21 15:11
330 查看
WCF 基础连接已经关闭: 连接被意外关闭。
这个错误可能一不小心就会碰到。总结起来应该有两种情况导致:
1、传输数据过大。
第一种情况,可以采取修改本地引用服务生成的节点内的属性解决。
binding节点中maxReceivedMessageSize的值增大即可。不过一般不建议这样使用,对于大批量数据可采取分页读取方式解决。因为大批量数据传输,影响传输速度并且容易出错。
2、传输类中的属性序列化问题
这种情况我正好碰到过。如下,
服务端类的是这样的,其它属性省略。
SDataModel model = new SDataModel();
model.ID = item.TBP_ID;
向客户端传输model对象时,没有包含Type。于是就报错了,而且怎么也检查不到,因为服务端执行也正常,但是客户端却异常了。
修改就是,在定义该字段时赋初值,改为
另一种如果使用ADO.NET Entity连接数据库生成数据模型时,要取消延迟加载。
其实在我碰到的问题中,主要是枚举类型传输问题。这里据我的理解就是。
序列化的过程是,序列化生成器将对象的基本类型 按照对象的结构 解析成流,然后传输。接收到以后,解析流中的内容,应该是将类型都变为字符串,通过字符串匹配的方式 和本地的基本类型的类型名匹配,然后恢复对象的类型,从而还原出原对象的结构和值。
但是对也这种自定义的枚举,如果没有赋值,是没有基本类型的,因此序列化就报错了。导致本地连接被关闭。而作为基本类型Int,String等因为是基类型,序列化中可以找到与之对应的类型,因此不会报错。
个人的一点观点,欢迎交流。
这个错误可能一不小心就会碰到。总结起来应该有两种情况导致:
1、传输数据过大。
第一种情况,可以采取修改本地引用服务生成的节点内的属性解决。
binding节点中maxReceivedMessageSize的值增大即可。不过一般不建议这样使用,对于大批量数据可采取分页读取方式解决。因为大批量数据传输,影响传输速度并且容易出错。
2、传输类中的属性序列化问题
这种情况我正好碰到过。如下,
服务端类的是这样的,其它属性省略。
[DataContract] public class SDataModel { private string id; private DataTypeEnum type; [DataMember] public string ID { get { return id; } set { id = value; } } [DataMember] public DataTypeEnum Type { get { return type; } set { type = value; } } } [DataContract] public enum DataTypeEnum { [EnumMember] 类型1 = 1, [EnumMember] 类型2 = 2, [EnumMember] 类型3 = 3, [EnumMember] 类型4 = 4 }当时有一个方法只需要少量的属性值就可以了,正好Type这个属性时不需要的。所以
SDataModel model = new SDataModel();
model.ID = item.TBP_ID;
向客户端传输model对象时,没有包含Type。于是就报错了,而且怎么也检查不到,因为服务端执行也正常,但是客户端却异常了。
修改就是,在定义该字段时赋初值,改为
[DataContract] public class SDataModel { private string id; private DataTypeEnum type=DataTypeEnum.类型1; [DataMember] public string ID { get { return id; } set { id = value; } } [DataMember] public DataTypeEnum Type { get { return type; } set { type = value; } } } [DataContract] public enum DataTypeEnum { [EnumMember] 类型1 = 1, [EnumMember] 类型2 = 2, [EnumMember] 类型3 = 3, [EnumMember] 类型4 = 4 }
另一种如果使用ADO.NET Entity连接数据库生成数据模型时,要取消延迟加载。
其实在我碰到的问题中,主要是枚举类型传输问题。这里据我的理解就是。
序列化的过程是,序列化生成器将对象的基本类型 按照对象的结构 解析成流,然后传输。接收到以后,解析流中的内容,应该是将类型都变为字符串,通过字符串匹配的方式 和本地的基本类型的类型名匹配,然后恢复对象的类型,从而还原出原对象的结构和值。
但是对也这种自定义的枚举,如果没有赋值,是没有基本类型的,因此序列化就报错了。导致本地连接被关闭。而作为基本类型Int,String等因为是基类型,序列化中可以找到与之对应的类型,因此不会报错。
个人的一点观点,欢迎交流。
相关文章推荐
- WCF-003:关于 WCF 基础连接已经关闭 连接被意外关闭-序列化问题
- WCF-005:关于 WCF 基础连接已经关闭 连接被意外关闭-不是使用父类指向子类问题
- WCF-005:关于 WCF 基础连接已经关闭 连接被意外关闭-不是使用父类指向子类问题
- wcf 基础连接已经关闭: 连接被意外关闭
- WCF项目中出现常见错误的解决方法:基础连接已经关闭: 连接被意外关闭
- WCF 基础连接已经关闭:连接被意外关闭
- WCF问题集锦:基础连接已经关闭 接收时发生错误
- wcf 基础连接已经关闭,连接被意外关闭
- 错误解决: WCF 基础连接已经关闭: 连接被意外关闭
- 关于 "基础连接已经关闭:接收时发生意外错误"
- WCF 基础连接已经关闭: 连接被意外关闭。
- 关于 "基础连接已经关闭:接收时发生意外错误"
- WCF项目中出现常见错误的解决方法:基础连接已经关闭: 连接被意外关闭
- 解决12306.cn网站验证码获取提示“基础连接已经关闭: 未能为 SSL/TLS 安全通道建立信任关系“的问题
- Post数据到 https异常:基础连接已经关闭: 连接被意外关闭 解决办法
- c# 基础连接已经关闭: 连接被意外关闭,错误的解决
- 解决连接vcenter (客户端无法向服务器发送完整的请求。(基础连接已经关闭:发送时发生错误。)) 问题
- httpWebRequest请求错误,基础连接已经关闭: 连接被意外关闭
- C# HttpRequest基础连接已经关闭: 接收时发生意外错误
- Entity Framework安装以及错误(基础连接已经关闭:未能为SSL/TLS……)问题解决!