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.
Related
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!
I have different XML files that I will need to read. I'm wondering if I should deserialize the files into custom objects or just read the data using XDocument objects and Linq-to-XML.
The files range in size from 1-2kb to 3mb+, and the different objects also range in complexity (some have attributes, some have children, some both, some none).
I figure it would be easier to work with the objects as opposed to Linq-to-XML, but creating those objects would require some time up front. Are there any rules of thumb or suggestions about when to deserialize as opposed to Linq?
Thanks for any help!
It really depends on what you are doing with the data. If you are not using all of the information that is provided by the XML document, then a LINQ based approach is probably easiest. Think of taking an RSS feed, and only keeping track of the article dates, and nothing else. In this case using a deserialization technique doesn't really do anything for you.
If you are using just about every last bit of data in the XML document, and its structure reflects that of your object model, then certainly deserialize it. This is something that I do all of the time for things like settings files, and even simple file formats.
In your case it sounds like it already exists, and was created by some external source, and you don't have an object representation of the data in your code already, so I would suggest using a LINQ based approach. Additionally, you mention a lot of variation in the files so the flexibility of LINQ would again come in handy. That is a wild guess based on your description though.
You could use the xsd.exe tool which could generate those classes from you given an XML file:
C:\work>xsd test.xml
C:\work>xsd /classes test.xsd
There is no really a rule of thumb. Personally I prefer working with strongly typed objects unless the file sizes become large in which case I switch to XmlReader.
I have this XML file, and I want to deserialize it to an object. But I don't want to type its class definition. There is any tool that can create the C# code of the class for me, inferring the data types from sample data?
Yes. Out of the box, you can use xsd.exe to generate XSD files from XML. You can also use this tool to generate classes from XSD files.
The code it produces is limited, which is why there are some third party tools that have stepped in.
Two of those tools include LiquidXML (costs money) and CodeXS (free). We use CodeXS, because it is free and extensible. We have extended it quite a bit.
EDIT:
CodeXS has an online tool. Just give it an XSD. It produces your classes for you.
They also have a command-line tool (source code) which is extensible and doesn't require you to send the XSD to their web service. We use it as a pre-build step.
Liquid Technologies has a good tool for this purpose (Data binding) http://www.liquid-technologies.com/. You'll really need to define a schema though instead of letting such a tool "infer" it from sample data.
One of the benefits of Liquid that we've found is that it can also generate code for Java, C++, C#, VBA etc. All very consistent.
Check out LINQ-to-XSD
It requires that you write a schema for your XML but then it's pretty good about a direct translation to objects.
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.
I'm considering Altova MapForce (or something similar) to produce either XSLT and/or a Java or C# class to do the translation. Today, we pull data right out of the database and manually build an XML string that we post to a webservice.
Should it be db -> (internal)XML -> XSLT -> (External)XML? What do you folks do out there in the wide world?
I would use one of the out-of-the-box XML serialization classes to do your internal XML generation, and then use XSLT to transform to the external XML. You might generate a schema as well to enforce that the translation code (whatever will drive your XSLT translation) continues to get the XML it is expecting for translation in case of changes to the object breaks things.
There are a number of XSLT editors on the market that will help you do the mappings, but I prefer to just use a regular XML editor.
ya, I think you're heading down the right path with MapForce. If you don't want to write code to preform the actual transformation, MapForce can do that for you also. THis may be better long term b/c it's less code to maintain.
Steer clear of more expensive options (e.g. BizTalk) unless you really need to B2B integration and orchestration.
What database are you using? Oracle has some nice XML mapping tools. There are some Java binding tools (one is http://java.sun.com/developer/technicalArticles/WebServices/jaxb). However, if you have the luxory consider using Ruby which has nice built-in "to_xml" methods.
Tip #1: Avoid all use of XSLT.
The tool support sucks. The resulting solution will be unmaintainable.
Tip #2: Eliminate all unnecessary steps.
Just translate your resultset (assuming you're using JDBC or equiv) to the outbound XML.
Tip #3: Assume all use of a schema-based tool to be incorrect and plan accordingly.
In other words, just fake it. If you have to squirt out some mutant SOAP (redundant, I know) payload just mock up a working SOAP message and then turn it into a template. Velocity doesn't suck.
That said, the best/correct answer, is to use an "XML Writer" style solution. There's a few.
The best is the one I wrote, LOX (Lightweight Objects for XML).
The public API uses a Builder design pattern. Due to some magic under the hood, it's impossible to create malformed XML.
Please note: If XML is the answer, you've asked the wrong question. Sometimes, we're forced against our will to use it in some way. When that happens, it's crucial to use tools which minimize developer effort and improve code maintainability.