Unexpected __-prefixed public variables in XSDObjectGen.exe auto generated code

Question

I have auto generated some classes from an xsd file using the XSDObjectGen.exe tool. My classes contain extra public variables, named using leading underscores, and I cannot figure out why.

Here's a sample from the xsd file:

<xs:attribute name="Fare" type="xs:int" use="required">
    <xs:annotation>
        <xs:documentation>The fare price in pence</xs:documentation>
    </xs:annotation>
</xs:attribute>

The corresponding auto generated C# code is:

[XmlAttribute(AttributeName = "Fare", DataType = "int")]
[EditorBrowsable(EditorBrowsableState.Advanced)]
public int __Fare;

[XmlIgnore]
[EditorBrowsable(EditorBrowsableState.Advanced)]
public bool __FareSpecified;

[XmlIgnore]
public int Fare
{
    get { return __Fare; }
    set { __Fare = value; __FareSpecified = true; }
}

I understand all of this code, including the attributes. However, I do not understand why it has been implemented this way.

• Why does this class serialize the __Fare rather than the Fare property? In this case the __Fare variable would be private (and renamed _fare) or an auto-property could be used.
• What is the purpose of the __FareSpecified variable?

Our feeling is that the __-prefixed variables are just going to add inconvenience for any developers who consume these classes, so plan to rewrite as follows:

[XmlAttribute(AttributeName = "Fare", DataType = "int")]
public int Fare{ get; set;}

Or even just:

[XmlAttribute]
public int Fare{ get; set;}

Can anyone shed any light on the rationale behind the __-prefixed variables?

Note that our xsd file is not expected to change often, if ever, so our ability to re-auto generate these classes is not important.

Edit

I double-checked with the team here, this source code was actually generated using XSDObjectGen.exe, not xsd.exe as I originally said.

Answer 1

Its to differentiate between the public property and its backing variable.

XSD does the XXXSpecified nonsense for non-nullable types.

I'm not a particular fan of the XSD tool because of stuff like this. Take a look at the XSDObjectGen or WSDL.EXE and see if they work better for you.