locked
type generation from DataContract schema RRS feed

  • Question

  • Hi,

    I have a requirement to have the DataContract definition as schema (xsd).

    And while usin g this DataContract in side my service, I will be using this as type.

    I am looking for the best possible ways to generate type from a given schema and vice versa.

    I tryed to use XSD tool, but this does not generate the type with DataContract attributes, instead it is using the xmlserilization.

    tryed to use the svcutil tool, this tool is not working if my datacontract contains XmlDocument type.

    given the above situation which tool is better?

    is there any other tool which I should try?

    Please send me your thoughts: comments / suggestions on this topic.

    Thanks,

    Venkat

    Monday, March 13, 2006 11:22 PM

Answers

  • You are using the "XmlDocument" class somewhere in your data contract, which is not a type that the DataContractSerializer can serialize - this is why you see the first error. Use "XmlElement" or "XmlNode[]" instead.

    As for the /ixt switch, it only works when importing schema into data contract types. (If you're only working with schema, not WSDL, you still also need the /dconly switch). The /ixt switch will loosen the rules for importing certain schema constructs. (Where we would normally fail, we would now generate IXmlSerializable types). If the schema was originally generated from data contract types, you don't need the /ixt switch to import it back in, just /dconly.

    Please note that a lot of these switches have now been renamed - I am not sure which names you'll see in your bits.

     

    Thursday, May 25, 2006 4:59 PM

All replies

  • Have you tried svcutil /dconly? Also to convert xsd to datacontract class you can use svcutil /dconly /ixt.
    Tuesday, March 14, 2006 5:17 AM
  • Venkat,

    Try to use svcutil with the /ixt switch

    Pablo
    Tuesday, March 14, 2006 4:19 PM
  • Hi,

    i tryed /dconly option and got the following error:

    C:\Venkat\Samples From MSDN>svcutil /dconly  "C:\Venkat\SOA Prototype\BusinessFl
    exServices\OMOIServices\OperatingInstructions\bin\OperatingInstructions.dll"
    Microsoft (R) Service Model Metadata Tool
    [Microsoftr .NET Framework, Version 3.0.50727.357]
    Copyright (c) Microsoft Corporation.  All rights reserved.

    Error: Type 'System.Xml.XmlDocument' has neither Serializable attribute nor Data
    Contract attribute

    If you are using the /dconly option to import DataContract types, consider using
     xsd.exe instead. If you are trying to generate service proxy code, consider usi
    ng the /useXmlSerializer option to explicitly import types using the XmlSerializ
    er.

    And tryed with /ixt option, got the following error:

    C:\Venkat\Samples From MSDN>svcutil /ixt  "C:\Venkat\SOA Prototype\BusinessFlexS
    ervices\OMOIServices\OperatingInstructions\bin\OperatingInstructions.dll"
    Microsoft (R) Service Model Metadata Tool
    [Microsoftr .NET Framework, Version 3.0.50727.357]
    Copyright (c) Microsoft Corporation.  All rights reserved.

    Error: Unable to read C:\Venkat\SOA Prototype\BusinessFlexServices\OMOIServices\
    OperatingInstructions\bin\OperatingInstructions.dll.
        The input read from 'C:\Venkat\SOA Prototype\BusinessFlexServices\OMOIServic
    es\OperatingInstructions\bin\OperatingInstructions.dll' is inconsistent with oth
    er options.

    If you would like more help, please type "svcutil /?"

     

    Any clue on what is happining?

    Thanks,

    Venkat

     

    Friday, March 17, 2006 12:29 AM
  • You are using the "XmlDocument" class somewhere in your data contract, which is not a type that the DataContractSerializer can serialize - this is why you see the first error. Use "XmlElement" or "XmlNode[]" instead.

    As for the /ixt switch, it only works when importing schema into data contract types. (If you're only working with schema, not WSDL, you still also need the /dconly switch). The /ixt switch will loosen the rules for importing certain schema constructs. (Where we would normally fail, we would now generate IXmlSerializable types). If the schema was originally generated from data contract types, you don't need the /ixt switch to import it back in, just /dconly.

    Please note that a lot of these switches have now been renamed - I am not sure which names you'll see in your bits.

     

    Thursday, May 25, 2006 4:59 PM