【问题标题】:WCF converting decimal value to zeroWCF将十进制值转换为零
【发布时间】:2016-03-08 18:50:56
【问题描述】:

我正在使用 SOAPUI 调用具有十进制值的 WCF 端点。某个地方的值被转换为零。

我可以使用来自 .NET 应用程序的相同参数调用相同的服务,并且值不会被更改。我可以反序列化并检查从我的 .NET 应用程序和 SoapUI 传递的值,并且对象的两个反序列化版本是相同的。

我已经能够在 Fiddler 中捕获离开 SoapUI 的请求并且十进制值仍然完好,所以我知道它正在某处向下流转换。

这篇文章表明在生成代理时可能会发生这种情况: int properties are 0 when consuming WCF in .Net 2 - 但证据并未表明这是服务中的问题,而不是客户端中的问题。

抱歉,由于公司隐私限制,我无法共享 WSDL 和 XML。

【问题讨论】:

  • 如果 SoapUI 将所有小数转换为零,您不会是第一个注意到的。请显示相关的 WSDL 和 XML。
  • xml架构中定义的数据类型是什么?
  • 绝对不是小数。感觉像是一个设定。由于公司对代码共享的限制,我无法显示 WSDL 或 XML :-(
  • @Rao - 不 - 它的值相同。我也可以分享,请求和原始值是<v12:TotalContentValue>8.000000</v12:TotalContentValue>
  • 谢谢@Rao。我已经用 Fiddler 跟踪了这条消息,并且可以证明它在 SoapUI 中没有被改变,而是在下游的某个地方。问题已更新以反映新发现。

标签: wcf decimal soapui zero


【解决方案1】:

在我的情况下,解决方案是更改我的请求参数的顺序。

我能够通过enabling WCF tracing(包括message payloads)确定这一点,然后将来自我的 .NET 应用程序的有效负载与来自 SoapUI 的有效负载进行比较。

有效负载有很大不同,但忽略命名空间、相关 ID、键和日期,我能够确定有问题的参数位于不同的位置。更改 SoapUI XML 请求中的顺序解决了这个问题。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2014-02-05
    • 2017-07-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-02-03
    • 2013-06-16
    相关资源
    最近更新 更多