I have XSD file, which seems rather complex (I am very new to working with XSD).
My task is to create a program, which would generate XML files based on the XSD schema (in a more detail - we will get a CSV file with the data and these need to be serialized into a XML). I did a research and tried various techniques of generating C# class from the XSD file, where the most 'compact' was xsd2code plugin for Visual Studio.
Nonetheless, this plugin has generated over 7,000 lines of code which quite shocked me as it was just one giant mess (for me).
My question now is - is there a better way (or maybe some switch I forgot to check) which will generate rather compact C# class? If not, then what is the next step that people have to do once they get C# class? Do they have to additional manual post processing so that the file is more 'programmer-friendly', or ...?
Thank you for your guidance; any help or tip will be highly appreciated!
Related
I am using XSD.exe to convert a pretty complex XML-Schema (XSD-file) to C# Classes. I am then using XmlSerializer to read XML into memory and work with the data.
In the future, the XSD will change. So there will be a new version. I will have to create a new cs file with XSD.exe. But I still want to support the old versions of XML files as well.
What is the best way to go about this and support both the old and new versions of XML files? Obviously, the classes XSD.exe creates will have the same names. So I can't really just generate another cs file in parallel with XSD.exe.
Any ideas are welcome. Thanks in advance!
XML Data Binding has the advantage of enabling you to code against strongly typed classes rather than untyped nodes, but this can make versioning tricky.
Information about this can be found in the 'Schema Versioning' section of Liquid XML Data Binder 2021 - Getting Started documentation.
Data binding technologies (that convert XSD definitions into types in a strongly-typed programming language) are an absolute pain when the schema is large, complex, or changing. My strong advice would be, find a different approach. I've earned a lot of consulting money helping people dig themselves out of this hole.
Use technologies that are better at coping with change and variety. XSLT, XQuery, LINQ, or even DOM if you must. XSLT and XQuery come with schema-awareness as an option so you can get some of the benefits (having your program code checked against the schema) without the heavy price of rebuilding and retesting your application every time there's a change.
Thank you for your answers.
For now, I placed the Code generated by XSD.exe in separate Namespaces and have them derive from a base class.
Like this, I can use either one or the other Class for generating/reading the XML. It appears to be working for me right now, as the Schema will not change without a new Version. Any changes made will be put into a new Version.
Working against an xsd and I need to give a list of all mandatory fields to a client
Is there a way i can quickly do in c#? or use a free tool?
File is quite big I would like to avoid to do it manually
thanks
you could try xsd2code which is a codeplex project. See here This makes classes within your code based on the Xsd format.
This is a free tool integrated into your visual studio and might help you find the necessary fields. As well that it allows you to create code easily to the xsd schema.
I have a rather large XSD file available here.
I want to generate the following from the file:
Generate DDL (for PostgreSQL), the DDL should contain initial values where appropriate, as specified by 'permitted' values in the XSD
Generate an ORM that will allow me to perform CRUD operations on the records in the database created in step 1
Can anyone suggest a tool or series of tools/technologies to achieve this?
In case I have to roll my own solution, can someone suggest a good tutorial for XSLT (preferably a cookbook - since I already know some XML/XPath).
Incidentally, I tried xsd.exe on Windows - it failed and printed an error message suggesting that there was a circular reference in the XSD file. I then tried xsd.exe on mono, that worked - but the file created had some invalid statements. I am guessing (perhaps incorrectly) that xsd.exe is NOT the way to achieve these twin goals - if I am wrong, let me know.
Also, I took at Ann Lewkowicz's XSLT transform file to generate a DDL from an XSD file - BUT that appeared to have got stuck in an infinite loop - and also complained about 'infinite recursion'
So I need help with the following:
First of all, can anyone test/check if the XSD file is indeed screwed up? - and if it is, how to fix it?
How do I go about generating a DDL and ORM from the XSD file?
Personally I would have written the generator myself. There may be good generators out there, but I haven't seen any. All I've tried using (though I never used an XSD as the starting point) generate terrible code, and worse, are rather impossible to customize to handle every quirk that inevitably turns up.
Doing so is a lot less work than people seem to imagine, and gives many benefits, not least that you'll actually have total control over exactly what is generated. And you could even (and quite easily) take it to the next level and generate the stuff at run-time. The latter is hardly meaningful if the schema is final, but can be a huge time-saver if it's constantly evolving.
I'm quite sure this isn't the answer you were hoping for, and I'd be interested too if anyone knows of good tools for the job.
Is there something available that could help me convert a XSD into SQL relational tables? The XSD is rather big (in my world anyway) and I could save time and boring typing if something pushed me ahead rather than starting from scratch.
The XSD is here if you want to have a look. It's a standardized/localized format to exchange MSDS.
Altova's XML Spy has a feature that will generate SQL DDL Script from an XSD file. XML Spy will cost you some money though.
Interestingly enough, a developer used a really clever trick of using an XSLT translation to create the DDL script from an XSD file. They have outlined it in two parts here and here.
I might have to try this out myself for future use...
EDIT: Just found this question asked previously here...
There is a command-line tool called XSD2DB, that generates database from xsd-files, available at sourceforge.
For more info: please refer to this existing question How can I create database tables from XSD files?
You can use an XSLT transform. See, for example, here: Generating SQL from XSD and XSL stylesheets with XSLT.
Microsoft has a command-line tool for performing XSLT transformations: Microsoft Command-Line tool for XSLT.
It is also easy to integrate the transforms into a build process using MSBuild or Grunt.
Here is the reference for the Microsoft documentation: XML Standards Reference, including XSD, XSLT, etc.
Using JAXB in Java it is easy to generate from a xml schema file a set of Java classes that xml conforming to that schema can be deserialized to.
Is there some C# equivalent of JAXB? I know that Linq can serialize and deserialize classes to/from xml files. But how can I generate C# classes from xml schema file and then use this classes with linq?
If you're using Visual Studio, try the XML Schema Definition Tool. It takes your schema definitions and produces C# classes -- or it can go the other way and produce schema definitions from classes. It also has a number of other XML-related transformations.
There is a better tool from Microsoft called XsdObjectGen, the XSD Object Code Generator. It is like xsd.exe, but better. Also free, it is not part of the .NET SDK, but is a separate download.
Also see the SO question: XSDObjectGen vs Xsd.exe
Look into using DataSet. It's a bit of a different concept from using "Java Beans". The entire XML document is treated hierarchical set of tables all in a single class. The good part is that theory of encapsulation for OOP is actually enforced. Wow, Microsoft got something right that Sun pooched.
Anyway. You can also look at typed DataSet's if you want make things more interesting. I've used this on major projects with great success.