Generate Model From An XSD schema

Topics: General Discussion Forum, Service Factory Modeling Edition Forum
Feb 2, 2009 at 11:09 PM
I am using the WSSF modeling edition for VS 2008. It seems there should be a way to start with an xsd schema file, and generate a model from the xsd. Does anyone know if it possible? 
Feb 3, 2009 at 3:09 PM
Yes it is possible. You need to add your schema file into the Schemas solution folder (or some other folder) and then add an CsdMessage element in your Service Contract model. You will find a property in your XsdMessage where you can point to the xsd type in your schema so you may generate your contracts using the types defined in your schemas.
For further details you can also take a look into on of the hands on labs http://go.microsoft.com/fwlink/?linkid=102972.
Feb 3, 2009 at 3:49 PM
Thanks for the qick reply, hernandelahitte. However -- no offense, but I don't believe this is correct. I have done the hands-on-lab you referenced. The procedure you described wires up schema types to a service contract created in an earlier step. If I am missing something, please correct me. I am hoping there is a way to avoid the tedious process of hand-creating a rather complex data model by using a pre-existing schema to generate the model. 

Thanks.
Feb 3, 2009 at 5:00 PM
I that case, what you can do is create the WSDL from your schema (if you already have the service contract defined) and use the Import WSDL extension to create the model. There are some restrictions but you may get basically the service contract out of your WSDL.
Feb 3, 2009 at 7:31 PM
No, the service contract is not defined yet. It is going to be very involved as well. Also, the ImportWSDL extension is for the WSSF source code release, whereas I am working with the binary release. I could install the source code release, but here's another thought... With the xsd.exe utility, I can (and did) generate C# classes from the xsd schema. However, there are no datacontract decorations on the classses, obviously. Is there anything useful in going down this path, or is the option you just outlined the only viable alternative to generating the data model?
Feb 3, 2009 at 8:06 PM
To get DC classes out of your schemas you should use svcutil.exe tool, not xsd.
Feb 3, 2009 at 10:11 PM
Hernan
Again, thanks for the replies. I knew svcutil.exe could be used on assemblies and meta data. However, I hadn't realized that could apply to an xsd file until now. I used svcutil as you suggested. Here is part of the resulting error message from using that command line utility:

(Command used: svcutil.exe /d:C:\TEMP\GeneratedCode /t:code C:\TEMP\SIF_Message.xsd /dconly)

"Error: Type 'SIF_MessageType' in namespace 'http://www.sifinfo.org/infrastructure/2.x' cannot be imported. Attributes must be optional and from namespace 'http://schemas.microsoft.com/2003/10/Serialization/'. Either change the schema so that the types can map to data contract types or use ImportXmlType or use a different serializer.

If you are using the /dataContractOnly option to import data contract types and are getting this error message, consider using xsd.exe instead. Types generated by xsd.exe may be used in the Windows Communication Foundation after applying the XmlSerializerFormatAttribute attribute on your service contract. Alternatively, consider using the /importXmlTypes option to import these types as XML types to use with DataContractFormatAttribute attribute on your service contract."

I ran the utility again using the /importXmlTypes switch. Code was generated, but it looks harder to work with than the code generated by the the xsd utility. The schema is provided by a standards organization, so changing the schema is not an option. I realized ahead of time that the schema was not compatible with DataContractSerialization. Since I was planning on using the ASMX implementation and XMLSerializer, I did not consider that a problem.

Any other thoughts? Or, have I run into a dead-end?

Feb 4, 2009 at 12:56 AM
For what it looks, this kind of brownfield scenario will better target the xsd.exe tool with XmlSerializerFormatAttribute in SC. 
Now back to my first post, I'm not sure why you can't use the XsdMessage approach (in this case with the XMLSerializer option set in the service contract model) and only model the service contract with the references to the schema types.
I guess that your schema only contains the data contract types so you will need to model the service contract anyway.
Feb 4, 2009 at 1:52 PM
Yes, you are correct. The schema only defines data, and the SC model will need to be done manually. I had intended on using the schema to wire up the various XsdMessage objects in the SC model, as you suggest. 

Are you saying that by doing these steps, there is a way of then generating the DC model? The DC model is the part for which I am trying to find a shortcut (by way of the xsd schema).
Feb 4, 2009 at 7:41 PM
Edited Feb 4, 2009 at 7:47 PM
I created a new project to try out what Hernan suggested. I made a  service contract containing only a couple of methods, imported the xsd schema, set some properties, created asmx implementation of guidance package and finally generated code by right-clicking on the service contract designer. I see that all the schema's data types were created as classes inside a project named "DataTypes". That is a hopeful sign. 

Not sure where to take it from here. I have a few questions:
- Does the DataTypes project in a ASMX implementation replace (or substitute for) the DataContract project in a WCF implementation?
- Can the DataContract model be reverse engineered at this point?
- Or, do I still need to create the DataContract model to get the full benefit of theWSSF modeling package?
- Depending on the above answer, do I still need the MessageContract project and the FaultContract project that are normally created by the guidance package? 
- Depending on the answer above, how to proceed?

Thanks again for all the help.
Feb 4, 2009 at 8:18 PM
Answers in order:
1) Yes
2) No.
3) You can create the DC model but ideally if you already have all the types defined in the schema, you may don;t need a DC model unless you want to add some additional type. However doing that may difficult maintenance of the schema and model as well. The recommended approach is tu use on of these two apporaches (contract first, schema or model first but not both).
4) You can remove these proyects if you don't use them.