2

I am currently trying to generate C# code using xsd.exe in order to use it with System.Xml.Serialization.

The command i am using is the next one:

xsd.exe path\to\eExact-XML.xsd /c /namespace:Namespace.Models /o:path\to\Namespace\Models

Alas, the generated code is not compileable due to the next generated snippet:

/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
public object System {
    get {
        return this.systemField;
    }
    set {
        this.systemField = value;
    }
}

One of the generated classes contains a property called System, which renders the following compiler error within the XmlElementAttribute:

eExact-XML.cs(25799, 60): [CS0120] An object reference is required for the non-static field, method, or property 'GLTransactionLineIntraStat.System'

My current solution is to simple remove the culprit from the generated class, but I don't find this an elegant solution.

Is there any way to tell xsd.exe to rename certain properties, or leave out parts of the xsd spec?

Wampie Driessen
  • 1,654
  • 1
  • 13
  • 19
  • Often there is more than one schema for an application and you need to add an include (see : https://www.w3schools.com/xml/el_include.asp). A schema often has user define optional items and you need a schema for the options. Adding the include will resolve missing items. – jdweng Dec 28 '20 at 13:29
  • @jdweng, thanks for your comment. The problem isn't missing items. The problem is that the `System` property hides the `System` namespace, which results in `System.Xml.xxx` to not being found – Wampie Driessen Dec 28 '20 at 15:04
  • Then change System to _System. So serialization still works and add above object [XmlElement("System")] – jdweng Dec 28 '20 at 15:25
  • If all else fails you could automate xsd with some .bat file where you would also somehow fix the issue. – Dialecticus Dec 28 '20 at 15:45
  • Seeing the same issue. We interface with an external system having a complex set of included/imported xsd files that we generate into classes. Same as you, a complexType named "System" generates a class named "System", which throws off pretty much every .NET type reference in the generated class. We have to manually update all .NET type references with a "global::" prefix, which isn't fun. Modifying the external system's schema is not an option. Did you ever find a way to supply name overrides or at least get the xsd.exe tool to put "global::" in front of .NET type references? – JCDrumKing Sep 30 '21 at 20:17
  • Actually I ended up implementing what @jdweng suggested and made a note for our other developers, explaining that anytime the schema files get updated to be sure and rename that one complexType to "_System" and update the one element declaration that references it to use "_System" as well. That's a heck of a lot easier than dorking with the type references in the generated class. The serialization/deserialization is not affected and all is well. – JCDrumKing Sep 30 '21 at 21:19
  • 1
    Hey @JCDrumKing, I have never found a solution to this problem. I tackled it the same way you did, with a lot of reluctance, as it felt like "not a real solution" – Wampie Driessen Oct 01 '21 at 12:15

0 Answers0