关于.NetCore与.Netframework 对于DataSet的序列化与反序列化问题的探讨.
最近完善自己的项目中,将很多原先的framework下的类库都转为.net standard类库,服务自然也往.netCore上转.因此,写了一个WebApi做为服务来完善自己的类库程序.
在我的程序体系中中有一部分的方式是要客户端传送Sql到服务端,服务端返回DataSet到客户端进行处理,WCF的服务端运行了7,8年了都很稳定,打算将WebApi的服务也完善进去.
这里自然最重要的一步就是DataSet的序列化和反序列化.
关于DataSet的序列化与反序列化,自然是用到了我十来年一直用的XmlSerializer类来进行,没有任何问题,没想到这里在反序列化时竟然报错,我都不敢相信自己的眼睛.
经过各种猜测,各种尝试后,发现如果客户端也用.NetCore,就不会报错.加之现在这个序列化的方式过于老旧,打算用比较新的Newtonsoft.Json来进行DataSet的序列化与反序列化,而且还用到专门序列化与反序列化DataSet的方法
StringDataSet = JsonConvert.SerializeObject(ds, new Newtonsoft.Json.Converters.DataSetConverter()); DataSet ds1 = JsonConvert.DeserializeObject<DataSet>(StringDataSet, new Newtonsoft.Json.Converters.DataSetConverter());
我还专门看了看序列化之后的字符串:
{"Table":[{"IP":"*.*.*.*","UUID":null,"key":"XYS.Lab.BLL.LoginDemo.GetUser","value":"select * from Users where loginname_str='{0}'","创建时间":"2020-04-07T14:44:28","修改时间":null,"ID":"68d26fac-ea54-4617-b5ea-c0777603df5c"}]}
我看到这个序列化后的字符串后,心就凉了,这tm的序列化完事了连个列的类型都不标注,百分百反序列化后会有问题,类型肯定是转换不对的.果不其然,虽然可以反序列化成DataSet,也有值,看着也对,但是往细里面看数据类型的时候,发现原本DataSet中的Guid类型,转换完成后变成了string类型.这让我很郁闷.
但是同时也给了我一个提示,是不是再用XmlSerializer序列化反序列化的时候,也是类型出了问题呢?
经过认真对比.NetCore下序列化的结果和.Net framework序列化后的结果发现了:
<xs:element name="UUID" msdata:DataType="System.Guid, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" type="xs:string" minOccurs="0" /> <xs:element name="UUID" msdata:DataType="System.Guid, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" type="xs:string" minOccurs="0" />
问题就出在这里,在.NetCore里和.Net framework里 对于这种特殊类型的序列化,做了详细的说明,连后面的DLL,版本号等详细信息都列出来了,所以自然转换不过来.
当我把.NetCore序列化的结果里关于Guid类型的这个描述替换成了.Netframework下的之后,反序列化成功了,而且很完美.但是这里还有一个问题,到底有多少种类型在序列化的时候跟Guid一样呢?我查了半天也没查到.
所以这里陷入了两难的境地.
用Newtonsoft.Json序列化实在是太粗了,反序列化后竟然有数据类型不一致的问题.
但是用XmlSerializer序列化又太tm的细致了,我可以替换一个Guid,但是不能保证所有的类似于Guid的类型都替换.
在此记录也算是给各位一个提醒,少走弯路,目前我大致的想法是先用Newtonsoft.Json做序列化,真的后面出现类型不一致造成问题了,再处理吧.
Newtonsoft.Json做序列化因为类型果然出现了问题,之前的代码在给dataset复制的时候,报错了,类型不对,看来目前还要用XmlSerializer序列化加上专门的字符串替换方式.