CODEWITHSUNDEEP
c#xmlxsd
Dai
Dai

Reputation: 155015

XSD to C# classes with control over name formatting

I'm working with an XSD file that uses UPPERCASE for element names and inconsistent attribute name casing. Unfortunately this cannot be corrected because the XML files that comply with this schema are read and written by programs hardcoded to expect those conventions.

I'm using Visual Studio 2013's xsd.exe tool to convert the XSD file into model classes, however XSD copies the element and type-names over verbatim and only applies the [XmlElement] or [XmlAttribute] attributes when a name isn't legal in C# (such as when a name contains a dash character).

Given this XML file:

<someIndustrialData>
    <FOOBAR name="foo" baz="BAR">
        <CHILDELEMENTS>
            <FOOBARCHILDELEMENT QUX="FOO">


            </FOOBARCHILDELEMENT>
            <FOOBARCHILDELEMENT qux="foo">

            </FOOBARCHILDELEMENT>
        </CHILDELEMENTS>
    </FOOBAR>
</someIndustrialData>

Consequently I have xsd.exe-generated output like this:

public partial class FOOBAR {
    public FOOBARCHILDELEMENT[] CHILDELEMENTS { get; set; }
}
public partial class FOOBARCHILDELEMENT {
    public String QUX { get; set; }
    public String qux { get; set; }
}

I don't like this.

I would prefer it if xsd.exe would generate this output instead:

[XmlElement("FOOBAR")]
public partial class FooBar {

    [XmlElement("CHILDELEMENTS")]
    public FooBarChild[] Children { get; set; }
}

[XmlElement("FOOBARCHILDELEMENT ")]
public partial class FooBarChild {

    [XmlAttribute("QUX")
    private String QUX { get; set; }

    [XmlAttribute("qux")
    private String qux { get; set; }

    public String Qux { get { return this.QUX ?? this.qux; } }
}

i.e.:

Is this possible?

Upvotes: 4

Views: 2906

Answers (2)

Rob Smyth
Rob Smyth

Reputation: 1858

This is an old post, but having had the same problem, here is my solution. You can control the class name that xsd.exe generates by using named complexTypes like this:

         // some code   
     <xs:element ref="person"/>
         // some code

  <xs:element name="person" type="PersonData"/>
  <xs:complexType name="PersonData">
          // some code
  </xs:complexType>

Here the a class PersonData is created for the XML element person. The generated output will be of the form:

public partial class PersonData {
   // generated class code
}

The result here is that xsd.exe will generate a class PersonData for element person.

Upvotes: 0

kjhughes
kjhughes

Reputation: 111491

This is probably not the answer you're looking for, but I'd recommend living with the unsightly capitalization convention simply because it best reflects the actual interface to your service. Why allow a slavish dedication to .NET coding conventions to create additional non-functional work for you now and additional support burden for you later?

If your team's purist sensibilities are offended by these admittedly hideous names, consider that a more productive use of its development time might be to build a non-interface-bound model appropriate for your domain. Coding directly against an interface model is non-ideal for substantial projects. If your project is quick-and-dirty or otherwise smallish, the bad names won't propagate far anyway. If your project is substantial, allow the bad names to accurately reflect the true interface names, and build separate, non-interface-bound, domain-based classes that provide a better model to code against (and secondarily can follow your prefered naming conventions).

Should you have or come to have additional interfaces to support (other XML schemas, JSON, etc), having domain-based code go against domain objects rather than interface objects will provide greater benefit in the long run than adherence to .NET naming conventions in the interface classes.

Upvotes: 3

Related Questions