Develop Reference

Why XmlDocument is using in Windows8 engine?

I guess that XmlDocument is deprecated class and we have to use XDocument instead. But TileUpdateManager.GetTemplateContent from Windows 8 UX core return XmlDocument class. As soon as it is new API, I'm wondering what reason for using XmlDocument here?

(I am using XDocument to refer to Linq2XML & XmlDocument to the System.XML api's)
Reasons I can see:
XDocument requires LINQ, which is .NET specific. Windows Store apps can be built in JavaScript too, so if you were to build a XDocument to work across both JavaScript & .NET then you would need to port LINQ too and now the engineering task is massive.
XDocument works with XML in a functional way, which is very not standard - the standard way to work with XML is via a DOM model. So XmlDocument provides the way that is more aligned with the way it works elsewhere.
I am guessing you are thinking they are separate API's - when XDocument builds on top of the normal XmlReader classes. So unless you completely rewrote XmlDocument you would always need it - and what is the value of rewriting something that works well just so you can hide it inside something else in the new version.
While a lot of cleanup & improvements have been done to the new API's has been done, remember it is still built on top of COM & a lot of the built in Windows API we currently have (this abstraction means should that change in the future it doesn't impact us, but currently it is not talking direct to the kernel), so likely they are leveraging the existing tools & libraries under the covers - which would all be DOM based and better aligned to XmlDocument.

XmlDocument class is in .Net for a while and they might have preferred to keep it like that. Another reason might be to have multi-language support.
You can wrap/decorate the function with another. There are various methods to convert XmlDocument to XDocument
private static XDocument DocumentToXDocument(XmlDocument doc)
{
return XDocument.Parse(doc.OuterXml);
}
private static XDocument DocumentToXDocumentNavigator(XmlDocument doc)
{
return XDocument.Load(doc.CreateNavigator().ReadSubtree());
}
private static XDocument DocumentToXDocumentReader(XmlDocument doc)
{
return XDocument.Load(new XmlNodeReader(doc));
}

XmlTextReader vs. XDocument

I'm in the position to parse XML in .NET. Now I have the choice between at least XmlTextReader and XDocument. Are there any comparisons between those two (or any other XML parsers contained in the framework)?
Maybe this could help me to decide without trying both of them in depth.
The XML files are expected to be rather small, speed and memory usage are a minor issue compared to easiness of use. :-)
(I'm going to use them from C# and/or IronPython.)
Thanks!

If you're happy reading everything into memory, use XDocument. It'll make your life much easier. LINQ to XML is a lovely API.
Use an XmlReader (such as XmlTextReader) if you need to handle huge XML files in a streaming fashion, basically. It's a much more painful API, but it allows streaming (i.e. only dealing with data as you need it, so you can go through a huge document and only have a small amount in memory at a time).
There's a hybrid approach, however - if you have a huge document made up of small elements, you can create an XElement from an XmlReader positioned at the start of the element, deal with the element using LINQ to XML, then move the XmlReader onto the next element and start again.

XmlTextReader is kind of deprecated, do not use it.
From msdn blogs by XmlTeam
Effective Xml Part 1: Choose the right API
Avoid using XmlTextReader. It contains quite a few bugs that could not be fixed without breaking existing applications already using it.
The world has moved on, have you? Xml APIs you should avoid using.
Obsolete APIs are easy since the compiler helps identifying them but there are two more APIs you should avoid using – namely XmlTextReader and XmlTextWriter. We found a number of bugs in these classes which we could not fix without breaking existing applications. The easy route would be to deprecate these classes and ask people to use replacement APIs instead. Unfortunately these two classes cannot be marked as obsolete because they are part of ECMA-335 (Common Language Infrastructure) standard (http://www.ecma-international.org/publications/standards/Ecma-335.htm) – the companion CLILibrary.xml file which is a part of Partition IV).
The good news is that even though these classes are not deprecated there are replacement APIs for these in .NET Framework already and moving to them is relatively easy. First it is necessary to find the places where XmlTextReader or XmlTextWriter is being used (unfortunately it is a manual step). Now all the occurrences of XmlTextReader should be replaced with XmlReader and all the occurrences of XmlTextWriter should be replaced with XmlWriter (note that XmlTextReader derives from XmlReader and XmlTextWriter derives from XmlWriter so the app can already be using these e.g. as formal parameters). The last step is to change the way the XmlReader/XmlWriter objects are instantiated – instead of creating the reader/writer directly it is necessary to the static factory method .Create() present on both XmlReader and XmlWriter APIs.
Furthermore, intellisense in Visual Studio doesn't list XmlTextReader under System.Xml namespace. The class is defined as:
[EditorBrowsable(EditorBrowsableState.Never)]
public class XmlTextReader : XmlReader, IXmlLineInfo, IXmlNamespaceResolver
The XmlReader.Create factory methods return other internal implementations of the abstract class XmlReader depending on the settings passed.
For forward-only streaming API (i.e. that doesn't load the entire thing into memory), use XmlReader via XmlReader.Create method.
For an easier API to work with, go for XDocument aka LINQ To XML. Find XDocument vs XmlDocument here and here.

Best way to manipulate XML in .NET

I need to manipulate an existing XML document, and create a new one from it, removing a few nodes and attributes, and perhaps adding new ones, what would be the best group of classes to accomplish this?
There are a lot of .NET classes for XML manipulation, and I'm not sure what would be the optimal way to do it.

If it is a really huge XML which cannot fit into memory you should use XmlReader/XmlWriter. If not LINQ to XML is very easy to use. If you don't have .NET 3.5 you could use XmlDocument.
Here's an example of removing a node:
using System.Xml.Linq;
using System.Xml.XPath;
var doc = XElement.Load("test.xml");
doc.XPathSelectElement("//customer").Remove();
doc.Save("test.xml");

Use Linq to XML You can see the XDocument class here

Parsing the document with XML Style Sheets might be the easiest option if it is just a conversion process.
Here is how to use XSLT in .NET.
and
Here is an introduction to XSLT.
It confused me a bit at first, but now I pretty much use XSLT to do all my XML conversions.

If you have an official schema, you can use the XmlSerializer. Otherwise it is best to use the XmlDocument, XmlNode, XmlElement etc classes.
Otherwise it could also depend on what you are using the xml for, i.e. marking up some document, representing objects etc.

XML Serialization, in this case, IXmlSerializable or Attributes

I've done some XML serialization before but i used Attributes, I'm not sure this is doable for my next assignment, here's a brief list of XML manip requirementes.
General Purpose XMl manipulation, tied to a treeview, no schema.
Load/Save XML.
Load/Save Attributes as well as Values (i believe the term is Element Text?), and be mindful of the Node's name.
Comments can be safely ignored as can Document info markup (ie, the UTF-8 and schema tags)
Any suggestions on how best to handle this?

I probably wouldn't bother with an object model and IXmlSerializable - it sounds like you might just as well talk in terms of an XmlElement / XmlDocument - i.e. pass the data around as a block of xml. Since you have no schema it would be pointless to shred it out; you might as well do it via an xml DOM.
When you say treeview - is this winforms, asp.net, wpf? I believe the asp.net treeview can take an xml source, but for winforms you'd have to iterate the nodes yourself.

Don't know what exactly you mean with "before but i used Attributes" but I would recommend XmlSerializer too:
With "simple" classes it works usually out of the box.
Collections might need some more work, but it depends on your requirements and object structure.
There are other build in XML serializers like XAML or the WCF DataContractSerializer. All have pros and cons. But if you want to fine tune your XML format, XMLSerializer is the most flexibel one.
You can approach your format step by step: If the default looks good, your done. If not you have to add just some attributes in most cases.
If you want complete control, you can still implement IXmlSerialize to fine tune your format.
Everything applies on a per class basis: Use the default where appropriate, add some attributes where required and implement IXmlSerializable as required.

I would suggest you to use the simple XML serialization supported by the .NET framework.
Go through these MSDN documentation
How to Serialize an object
How to Deserialize an object

DeSerializing an XML file to a C# class

Does anyone know what advantages (memory/speed) there are by using a class generated by the XSD tool to explore a deserialized XML file as opposed to XPATH?

I'd say the advantage is that you get a strongly typed class which is more convenient to use, and also the constructor for the class will throw an exception if the XML data in the file is invalid for creating the object, so you get a minimal data validation for free.

If you don't want to write boilerplate code, and you need to check ANY values of your XML on the way through, you can't go wrong with the XSD.exe generated classes.

The two are very different; but XmlSerializer will always deserialize entire objects; with XPath you can pick and choose. I'd use XmlSerializer personally, though - harder to get wrong.
XPath, however, is a complex beast that depends on the back-end. For example, XmlDocument (mutable) will behave differently to XPathDocument (read-only, optimized for query).