WCF IsReference = true 正在将值重置为默认值
我有一个非常简单的 WCF 4.0 服务,其中我返回一个 POCO 实体对象,其 IsReference 设置为 true。当我从服务返回对象时,基本类型(int、double等)的值被正确设置,并且具有引用的值也被正确序列化,我已经验证序列化是否正确发生,在返回之前放置以下代码陈述。我还验证了成员是否正确标记为 [DataMember] 并且它们具有公共 getter/setter。然而,当调用者接收到该对象时,所有原始类型都将被设置为 0,而带有引用的类型将被设置为 NULL。
将不胜感激任何帮助!
try
{
var stream = new MemoryStream();
var dataContractSerializer = new DataContractSerializer(onlineSellItemDetail.GetType());
dataContractSerializer.WriteObject(stream, onlineSellItemDetail);
}
catch (Exception ex)
{
Console.WriteLine(ex.InnerException.ToString());
}
I have a very simple WCF 4.0 service in which I am returning an POCO entity object whose IsReference is set to true. When I return the object from my service, the values of primitive types (int, double, etc) are set correctly and the ones having references are also getting serialized properly, I've verified that the serialization happen correctly putting following code just before return statement. I've also verified that the members are correctly marked with [DataMember] and they have public getters/setters. However, when the object is received by the caller, all the primitive types are set to 0 and the ones with references are set to NULL.
Would appreciate any help!
try
{
var stream = new MemoryStream();
var dataContractSerializer = new DataContractSerializer(onlineSellItemDetail.GetType());
dataContractSerializer.WriteObject(stream, onlineSellItemDetail);
}
catch (Exception ex)
{
Console.WriteLine(ex.InnerException.ToString());
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这几乎总是因为客户端没有收到 XML、空 XML 或不兼容的 XML。有时,这是因为流在服务端没有正确刷新或关闭。其他时候,客户端在其自己的流中使用完全有效的 XML 进行操作,但可能不是从流的开头开始读取 XML。如果您在服务端和客户端上启用跟踪,生成跟踪日志,并使用 SvcTraceViewer 进行分析,同时使用 Fiddler 监控客户端和服务端的线路流量,我想您会发现肯定回答!
This is almost always because no XML, empty XML, or incompatible XML was received on the client end. Sometimes, this is because the stream was not flushed or closed properly on the service side. Other times, the client side is operating with completely valid XML in its own stream, but is reading the XML by perhaps not starting at the beginning of the stream. If you enable tracing on the service side and the client side, generate tracing logs, and analyze with SvcTraceViewer, and in parallel, use Fiddler to monitor the wire traffic on both the client side and the service side, I think you'll find the answer for sure!