Question

I’ve worked with WCF for awhile now and in places where both client and server tend to be co-released; that is, new versions have almost always been released at the same time. Interoperability and versioning aren’t issues (in this case at least).

The MSDN documentation, DataMemberAttribute.EmitDefaultValue and Data Contract Versioning, suggests it is a bad practice to emit the default value unless there is a specific need and to support versioning.

In practice, I’ve found it useful and at times critical to omit the default value, especially when a WCF service must call back multiple clients. At times of high load, the bigger messages place high memory pressure on the server and take longer to transmit.

Are there any other reasons why this should be avoided?

Answer 1

I am also using DataMemberAttribute.EmitDefaultValue = false in some spots to try and limit the amount of data being transmitted. In my case, I am in control of both the client and server side of things, so I don’t have any problems with it.

I did find a reference to a potential conflict with DataMemberAttribute.IsRequired, which I didn’t know about before:

Interaction with IsRequired

…If IsRequired is set to
true, (which indicates that a value must be present) and
EmitDefaultValue is set to false (indicating that the value must not
be present if it is set to its default value), default values for this
data member cannot be serialized because the results would be
contradictory. If such a data member is set to its default value
(usually null or zero) and a serialization is attempted, a
SerializationException is thrown.

Normally, this shouldn’t be a problem because as soon as you try to serialize an object with a member marked with EmitDefaultValue = false, IsRequired = true, and a default value, you get a SerializationExeception, so the problem is very obvious (I just tested it out). However, I could see situations where the EmitDefaultValue is false and at some later time, IsRequired is set to true, creating problems (hopefully caught in testing before the change is deployed).

One more possible problem with this combination: a client could send data with a default value, and this will be deserialized without a problem. Your service might then save it to the database, and then attempt to send it back out, which will throw an exception.

All that being said, I think you are using the setting for the specific reasons noted in the documentation. Just be aware of the potential conflict with IsRequired.