WCF chokes on properties with no "set ". Any workaround?

Question

I have some class that I'm passing as a result of a service method, and that class has a get-only property:

[DataContract]
public class ErrorBase
{
  [DataMember]
  public virtual string Message { get { return ""; } }
}

I'm getting an exception on service side:

System.Runtime.Serialization.InvalidDataContractException: No set method for property 'Message' in type 'MyNamespace.ErrorBase'.

I have to have this property as only getter, I can't allow users to assign it a value. Any workaround I could use? Or am I missing some additional attribute?

Solution 1

Give Message a public getter but protected setter, so that only subclasses (and the DataContractSerializer, because it cheats :) may modify the value.

Solution 2

Even if you dont need to update the value, the setter is used by the WCFSerializer to deserialize the object (and re-set the value).

This SO is what you are after: WCF DataContracts

Solution 3

[DataMember(Name = "PropertyName")]
public string PropertyName
{
    get
    {
        return "";
    }
    private set
    { }
}

Solution 4

If you only have a getter, why do you need to serialize the property at all. It seems like you could remove the DataMember attribute for the read-only property, and the serializer would just ignore the property.

Solution 5

Couldn't you just have a "do-nothing" setter??

[DataContract]
public class ErrorBase
{
  [DataMember]
  public virtual string Message 
  {
      get { return ""; } 
      set { }
  }
}

Or does the DataContract serializer barf at that, too??

View more solutions

Comments

[Andrey]

So the only way for me to overcome the problem is to make it a method instead of property? Again, I can't allow "set" on this property

[Russell]

You could make it a method (eg GetMessage() { return ""; }) alternatively, I am pretty sure you could tell the WCF Serializer to ignore it. I'll see what I can find and let you know.,

[Russell]

This stackoverflow question hits the nail on the head: stackoverflow.com/questions/172681/wcf-datacontracts

[rh.]

Thanks, glad it was useful! This actually is just one of several uses for this trick. Since getters and setters are technically functions, you can also use this same technique to provide custom serialization of primitive types (perhaps a custom time format in XML) without needing to wield the intimidating IDataContractSurrogate.

[Andrey]

It doesn't barf, I just didn't want to let the developers using the client API think that they can assign stuff to the property.

[Aisah Hamzah]

You could even make it private. The Serializer doesn't mind whether it's private, public, protected, internal or protected internal.

[aruno]

and make the setter throw new NotSupportedException()

[Thomas Hagström]

Dont' forget the [DataMember] attribute :)

[Florian Winter]

It does indeed not make sense to serialize a derived property (e.g., an URL property that is computed from an ID property) to a persistent storage (e.g., a database) - upvote for that - but it does make sense to serialize it to a representation (e.g., JSON or XML) that is returned by an API request.

[user276648]

Having a private set; works if you use [DataContract] and [DataMember]. If you omit them, you need public set;.