Question

Is there any switch that instructs svcutil to generate DataContract properties with their names as defined in code? For example when I create a proxy which uses the following DataContract:

[DataContract(Namespace = "http://schemas.mynamespace.com/2012/08")]
public class MyDataContract
{
    [DataMember(IsRequired = true, Order = 0)]
    private int _id;

    public int Id
    {
        get { return _id; }
        set { _id = value; }
    }
}

I get this DataContract on the proxy generated class:

public partial class MyDataContract : object
{                
    private int _idField;

    [System.Runtime.Serialization.DataMemberAttribute(IsRequired=true)]
    public int _id
    {
        get
        {
            return this._idField;
        }
        set
        {
            this._idField = value;
        }
    }
}

The order property of the DataMemberAttribute is always ommited as well for the first 3 properties and a MessageContract ommits an IDisposable implementation.

Answer 1

Well, I cannot comment on the omitted order, but I may be able to help on the rest:

• One usually specifies the DataMember attribute on the property, not on the field. The data-contract itself does not distinguish between a property and a field, but it knows the name, type, if it is mandatory, etc. etc.

• Added: What Chris said: With [DataMember(Name="whateveryouwant")] you’ll be able to set a name different from the field/property name. I do not like such usage, though, but it is helpful when refactoring code, but still keeping the API compatible.

• Only other DataContract (and some intrinsically supported) types are serialized to/from messages. IDisposable seems not to be one.

• Serializing the inherited IDisposable of a MessageContract would not make any sense. A message-contract is the .NET representation of a SOAP message. It literally has nothing else to do but to provide a 1:1 mapping between what is in the SOAP message XML, and the accessible .NET types.

  A message is part of a ServiceContract, in that it specifies which kind of message must be sent to a certain operation to be a valid invocation, and another (response-)message contract specifies how the data, that the operation returns, will be structured. Nothing else; it is a data-aggregate.

If you want to capture the result of a service-operation on the client, and for convenience automatically send a message back upon going out of scope (or for instance unregistering from a service), you will have to implement this on the client-side. Be aware, however, that the service must not require this to happen (due to lost connections, crashes, etc.).