System.Xml 中的新增功能
下面的 System.Xml 功能是 .NET Framework 中的新功能：支持 W3C 第四版的 XmlConvert 方法。
新的 XmlConvert 方法
XmlConvert 类的新成员允许将特定的字符或字符串作为特定 XML 标记或有效 XML 进行验证：
public static bool IsNCNameChar(char);
public static bool IsPublicIdChar(char);
public static bool IsStartNCNameChar(char);
public static bool IsWhitespaceChar(char);
public static bool IsXmlChar(char);
public static bool IsXmlSurrogatePair(char, char);
public static string VerifyPublicId(string);
public static string VerifyWhitespace(string);
public static string VerifyXmlChars(string);
Visual Studio 2010 中的重大更改
以下各节是 System.Xml 中的重大更改：
在与 XML 相关的类中更改了 NullRefenceExceptions
在加载样式表时，XslCompiledTransform 类可引发 NullReferenceException。
XmlNode.InnerText 可引发 NullReferenceException。
当其构造函数的某些参数为 null 时，XmlValidatingReader 类可引发 NullReferenceException。
更改这些行为是为了引发更有用的异常，从而简化对代码的调试。
XmlWriter.Dispose 不再禁止显示所有异常
XmlWriter.Dispose 以前禁止显示所有异常（包括不应被捕获的异常，例如 OutOfMemoryException）。XmlWriter.Dispose 已更改为引发有用的异常。
在包含到多个架构中时，Chameleon 架构现在能正确克隆
当有些架构包含在另一个 XSD 中时，如果这些架构没有目标命名空间（也称为 Chameleon 架构，以前用于在架构中包含通用类型），则它们会采用导入架构的目标命名空间。
如果有两个架构包含在一个 XmlSchemaSet 中，并且这两个架构均包含在 Chameleon 架构中，则 Chameleon 架构不能正确克隆到这两个架构中。这会影响 XML 验证。不正确的验证可能会导致数据损坏。
现在克隆能够正常执行。
在调用 MoveToAttribute(Int32) 之后，XsdValidatingReader.MoveToNextAttribute 现在能正确执行
由于当前特性索引从未更新，XsdValidatingReader.MoveToAttribute(Int32) 中的 Bug 会使 MoveToNextAttribute 失败。这就使多态性无法处理 XsdReader 的不同子类。
在调用 MoveToAttribute(Int32) 之后，XsdValidatingReader.MoveToNextAttribute 现在将正确执行。
XmlReader.ReadContentAs 不再忽略 IXmlNamespaceResolver 中的已传递内容
接受 IXmlNamespaceResolver 的 XmlReader.ReadContentAs 方法现在将使用 IXmlNamespaceResolver 参数作为命名空间解析器。以前，会忽略 IXmlNamespaceResolver 参数，并使用 XmlReader 作为命名空间解析器。
即使从未调用要测试的函数，“函数可用”XSLT 函数现在也能正确执行
“函数可用”函数用于确定具有特定名称的函数是否可用。以前，如果未在 XSLT 中调用过该函数，则即使该函数可用，“函数可用”函数也始终返回 false。在 MSXML3 SP1 中也修复了这一错误。
已修复 XmlSchemaSet 中的依赖项 Bug
XmlSchemaSet 允许编译 XSD 架构。这些架构可包含其他架构（A.xsd 可以包含 B.xsd，而后者又可以包含 C.xsd）。编译这些架构中的任意架构，都会导致遍历依赖项图。以前，当此集合中的架构被修改并且依赖架构被重新编译或重新处理时，不能正确遍历架构的依赖项图，从而导致编译不一致的架构。
XmlReader.Create 返回会错误放弃有意义的空格的读取器
XML 验证能够识别包含文本和 XML 标记的混合内容模式。在混合模式下，所有空格都是有意义的，应该报告出来。以前，XsdValidatingReader 会将有意义的空格报告为无意义。
在将数据加载到 XmlDocument 或 XDocument/XElement 中时，这些对象在默认情况下会去除无意义的空格，因此以前的行为可能会导致数据损失。
包装 XmlWriters 时不遵循 NewLineHandling.None
如果您创建一个包装 XmlWriter（指写入另一个 XmlWriter 的 XmlWriter）并指定该包装 XmlWriter 具有 NewLineHandling.None，则当您使用 WriteChars 方法并且内容包含 /r/n 时，输出也包含 /r/n/r/n（数据损坏）。此行为会影响两个常见的方案。
在使用从 XmlSerializer 创建的现有 XmlWriter，然后包装该写入器时。如果所生成的 XML 的使用者不能接受空格（例如，第三方 Web 服务），可能会出现意外行为。
在使用 XmlWriter 将内容插入到现有 XmlDocument 或 XDocument 中时。以前的行为不能为添加到文档中的内容正确规范化新行。
修复此问题后，NewLineHandling.None 可让包装写入器表现出正确的行为。
在 XmlWriter 中，实体引用在 XML 特性中被实体化两次
如果用户尝试使用 XmlWriter.WriteEntityRef 将实体写入 xmlns 特性或者写入 xml:lang 或 xml:space 特性中，该实体在输出中将被实体化两次，从而导致数据损坏。
XmlWriter w = XmlWriter.Create(Console.Out);
w.WriteDocType("root", null, null, "<!ENTITY e \"en-us\">");
w.WriteStartElement("root");
w.WriteStartAttribute("xml", "lang", null);
w.WriteEntityRef("e");
w.WriteEndAttribute();
w.WriteEndElement();
w.Close();
输出：
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
应为：
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
现在，实体不会被实体化两次。
XNode.CreateReader 返回正确的 BaseURI
如果您使用 CreateReader 从 LINQ to XML 类创建了 XmlReader 对象，在调用 Read 之前，该读取器不会返回正确的 BaseURI。因此，在首次调用 Read 之前依赖于 BaseURI 值的代码将在调用（直接从您的代码调用或通过其他调用来调用）Read 之后发生变化，就像将 XmlReader 传递给了另一个方法。
将 XSLT 与 LINQ to XML 一起使用，XSLT ID 函数现在能返回正确的值
如果您使用 CreateReader 函数从 LINQ to XML 类创建一个 XmlReader 对象，并且将此 XmlReader 传递给 XSLT，则 XSLT 中 ID 函数的任何实例以前都会返回 null。null 不是 ID 函数的有效返回值。任何依赖于值为 null 的 ID 的代码都需要更改。
DocumentXPathNavigator 现在能正确报告 x:xmlns 特性的本地名称
DocumentXPathNavigator 以前为 x:xmlns 特性的本地名称返回空字符串。以前的行为可能会导致数据损坏，并且在某些情况下会禁止使用 XSLT 生成 XSLT。
本地名称现在能够正确返回，因此可以使用 XSLT、生成其他 XSLT 的代码或返回 x:xmlns 的文档。
对子树执行 XsltReader 和 XmlReader，不会在一个 XML 元素中创建重复的命名空间声明
在用 XsltReader 读取 XSLT 时，如果 XmlReader 位于 XsltReader 之上，则产生的 XML 元素将包含重复的命名空间声明，从而导致无效的 XML，并且可能使某些 XML 处理器产生问题。
以前的这种行为可能会导致数据损坏，并禁止从 XmlReader 创建有效的 XML。