WCF 和 ObservableCollection- 物品在那里，但空着？
我在 WCF 服务上有一个方法，该方法返回 ObservableCollection。在服务器端，在返回结果之前，我可以看到集合中填充了项目，并且项目包含预期的数据。在客户端，该集合填充了与服务器端相同数量的项目，但每个项目中的所有属性均为 null（有四个字符串和一个枚举类型）。
返回的项目的类型声明未使用 [DataContract] 和 [DataMember] 属性进行修饰，因为它驻留在共享 .dll 中，并且尚未经过到目前为止，该程序集中的任何其他类型都是一个问题。这种特殊类型用 [Serializing] 属性修饰。在 Fiddler 中捕获响应表明这些项目在反序列化之前仍然包含数据。为什么项目属性的值会在反序列化中丢失？
I've got a method on a WCF service that returns an ObservableCollection<T>. On the server side, before returning the result, I can see that the collection is populated with items and the items contain the data as expected. On the client side, the collection is populated with the same number of items as on the server side, but all of the properties in each item are null (there are four strings and an enumerated type).
The type declaration for the items being returned is not decorated with the [DataContract] and [DataMember] attributes, as it resides in a shared .dll, and this has not been a problem for any other types in this assembly until now. This particular type is decorated with the [Serializable] attribute Catching the response in Fiddler shows that the items still contain data before being deserialized. Why would the values of the items' properties be lost in deserialization?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只是为了好玩，我用
[DataContract]和[DataMember]属性装饰它，这就达到了目的。看来枚举没有正确序列化/反序列化。但希望我能更好地了解原因。Just for kicks I decorated it with
[DataContract]and[DataMember]attributes, and that did the trick. It would appear that the enum didn't serialize/deserialize correctly. Wish I had a better idea as to why, though.dll 中的类型定义应标记为可序列化。
The type definitions in the dll should be marked serializable.