我有一个WCF服务,它公开了一个方法,该方法返回一个包含Image属性的对象数组(参见下面的代码).在同一个解决方案中,我有一个类库项目,它有一个对我的WCF项目的服务引用.在类库中,当我尝试"更新服务引用"时,我的代理类变得不可用.当我从我的类中删除"Graphic"属性时,我没有任何困难更新类库中的服务引用,我的代码都编译并运行正常.我把"Graphic"属性重新放入,代理类再次变得不可用.更奇怪的是,服务引用所暴露的唯一类是"Image".
我在这里俯瞰什么?
[Serializable]
public class PhotoDTO
{
public Guid Id { get; set; }
public Image Graphic { get; set; }
}
[ServiceContract]
public interface IGeneralService
{
[OperationContract]
PhotoDTO[] GetPhotos(Guid subsectionId);
}
Run Code Online (Sandbox Code Playgroud)
编辑:正如alexdej正确指出的那样,Image将正确地使用DCS序列化/反序列化,但您必须将DataContract类型更改为Bitmap或使用config在运行时为System.Drawing.Image指定Bitmap的KnownType(您不能属性,因为你没有Image类).
Image类不适合DataContractSerializer进行序列化 - 它与GDI缓冲区和封装内容有各种联系.DCS旨在表示控制类的整个结构的数据对象.之所以引起混淆,是因为在3.5SP1中,他们为DCS添加了序列化未使用DataContractAttribute标记的对象的能力(主要是为了方便那些懒得将其线类属性化的人).不幸的副作用是序列化程序很乐意尝试序列化任何旧对象,但在许多情况下(如你的)无法产生有用的结果.
无论如何,您需要将其转换为byte []或Stream以通过线路将其转换为水,并将其重新水合为图像.如果您在两侧使用WCF和相同的DataContract类型(例如,不是生成的类型),则可以将Graphic保留为属性,但不要使用DataMember标记它.通过将Image.Save调用到MemoryStream,然后转储byte [],使图形填充存储为另一个属性ImageBytes(标记为DataMember).使ImageBytes上的set以相同的方式从传入的byte []加载图形属性的内部Image存储.当对象在另一端被反序列化时(例如,反序列化器调用ImageBytes setter),poof-你的Graphic属性的存储被填充,并且一切正常.全自动序列化/反序列化行为 - ImageBytes属性只是一个实现细节.
| 归档时间: |
|
| 查看次数: |
3619 次 |
| 最近记录: |