DataContract properties names during proxy generation with svcutil

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.

score 1 · Answer 1 · answered Aug 29 '12 at 10:20

1

Use the name property on DataMember attribute

Such as:

[DataMember(Name="myname")]

answered Aug 29 '12 at 10:20

Chris

2,471
25
36

score 1 · Accepted Answer · edited May 23 '17 at 12:04

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.).

Ah, right. This is also specified in the tenets of WCF about the IDisposable implementation. Silly of me, not to think about it. About the `Property` name though, which is the preferred way? Having just public `Properties` where the `DataContractAttribute` will be applied without using private fields at all or keep the private fields and apply the attr straight on the `Property` ? — Pantelis, Aug 29 '12 at 10:29
On a second thought, it doesn't make sense to keep the private fields since the `Attribute` is applied on the `Property`, does it? — Pantelis, Aug 29 '12 at 10:32
I recommend just using the plain auto-property. Why? Last time I checked, WCF was not able to use fully immutable DataContract types, and immutability is the most common reason to write out the private (readonly) field oneself (of course there are some others, like cache-magic etc.). — gimpf, Aug 29 '12 at 20:19

DataContract properties names during proxy generation with svcutil

2 Answers2