How to deal with XML in C#

Question

So what is the best way to deal with XML documents, XSD and all that stuff in C# 2.0? What classes to use etc. Like what are the best practices of parsing and making XML documents etc.

EDIT: .Net 3.5 suggestions are also welcome.

Answer 1

It depends on the size; for small to mid size xml, a DOM such as XmlDocument (any C#/.NET versions) or XDocument (.NET 3.5/C# 3.0) is the obvious winner. For using xsd, You can load xml using an XmlReader, and an XmlReader accepts (to Create) an XmlReaderSettings. The XmlReaderSettings objects has a Schemas property that can be used to perform xsd (or dtd) validation.

For writing xml, the same things apply, noting that it is a little easier to lay out content with LINQ-to-XML (XDocument) than the older XmlDocument.

However, for huge xml, a DOM may chomp too much memory, in which case you might need to use XmlReader/XmlWriter directly.

Finally, for manipulating xml you may wish to use XslCompiledTransform (an xslt layer).

The alternative to working with xml is to work with an object model; you can use xsd.exe to create classes that represent an xsd-compliant model, and simply load the xml as objects, manipulate it with OO, and then serialize those objects again; you do this with XmlSerializer.

Answer 2

First of all, get to know the new XDocument and XElement classes, because they are an improvement over the previous XmlDocument family.

1. They work with LINQ
2. They are faster and more lightweight

However, you may have to still use the old classes to work with legacy code - particularly previously generated proxies. In that case, you will need to become familiar with some patterns for interoperating between these XML-handling classes.

I think your question is quite broad, and would require too much in a single answer to give details, but this is the first general answer I thought of, and serves as a start.

Answer 3

If you're working in .NET 3.5 and you aren't affraid of experimental code you can check out LINQ to XSD (http://blogs.msdn.com/xmlteam/archive/2008/02/21/linq-to-xsd-alpha-0-2.aspx) which will generate .NET classes from an XSD (including built in rules from the XSD).

It then has the ability to write straight out to a file and read from a file ensuring that it conforms to the XSD rules.

I definately suggest having an XSD for any XML document you work with:

• Allows you to enforce rules in the XML
• Allows others to see how the XML is/ will be structured
• Can be used for validation of XML

I find that Liquid XML Studio is a great tool for generating XSD's and it's free!

Answer 4

101 Linq samples

http://msdn.microsoft.com/en-us/library/bb387098.aspx

and Linq to XML samples

http://msdn.microsoft.com/en-us/vbasic/bb688087.aspx

And I think Linq makes XML easy.

Answer 5

If you create a typed dataset in the designer then you automatically get an xsd, a strongly typed object, and can load and save the xml with one line of code.

Answer 6

nyxtom's answer is very good. I'd add a couple of things to it:

If you need read-only access to an XML document, XPathDocument is a much lighter-weight object than XmlDocument.

The downside of using XPathDocument is that you can't use the familiar SelectNodes and SelectSingleNode methods of XmlNode. Instead, you have to use the tools that the IXPathNavigable provides: use CreateNavigator to create an XPathNavigator, and use the XPathNavigator to create XPathNodeIterators to iterate over the lists of nodes you find via XPath. This generally requires a few more lines of code than the XmlDocument methods.

But: the XmlDocument and XmlNode classes implement IXPathNavigable, so any code you write to use those methods on an XPathDocument will also work on an XmlDocument. If you get used to writing against IXPathNavigable, your methods can work against either object. (This is why using XmlNode and XmlDocument in method signatures is flagged by FxCop.)

Lamentably, XDocument and XElement (and XNode and XObject) don't implement IXPathNavigable.

Another thing not present in nyxtom's answer is XmlReader. You generally use XmlReader to avoid the overhead of parsing the XML stream into an object model before you begin processing it. Instead, you use an XmlReader to process the input stream one XML node at a time. This is essentially .NET's answer to SAX. It lets you write very fast code for processing very large XML documents.

XmlReader also provides the simplest way of processing XML document fragments, e.g. the stream of XML elements with no encluding element that SQL Server's FOR XML RAW option returns.

The code you write using XmlReader is generally very tightly coupled to the format of the XML it's reading. Using XPath allows your code to be much, much more loosely coupled to the XML, which is why it's generally the right answer. But when you need to use XmlReader, you really need it.

Answer 7

Cookey's answer is good... but here are detailed instructions on how to create a strongly typed object from an XSD(or XML) and serialize/deserialize in a few lines of code:

Instructions

Answer 8

My personal opinion, as a C# programmer, is that the best way to deal with XML in C# is to delegate that part of the code to a VB .NET project. In .NET 3.5, VB .NET has XML Literals, which make dealing with XML much more intuitive. See here, for example:

Overview of LINQ to XML in Visual Basic

(Be sure to set the page to display VB code, not C# code.)

I'd write the rest of the project in C#, but handle the XML in a referenced VB project.