下列 System.Xml 功能是 .NET Framework 中的新功能：XmlConvert 方法，支援 W3C 第四版。
新的 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 相關類別中已變更的 NullRefenceException
XslCompiledTransform 類別可能會在載入樣式表時擲回 NullReferenceException。
XmlNode.InnerText 可能會擲回 NullReferenceException。
XmlValidatingReader 類別可能會在其建構函式的某些引數為 null 時擲回 NullReferenceException。
這些已經變更為擲回更有用的例外狀況，使偵錯程式碼更為容易。
XmlWriter.Dispose 不再隱藏所有例外狀況
XmlWriter.Dispose 先前會隱藏所有例外狀況 (包括不應該攔截的例外狀況，例如 OutOfMemoryException)。XmlWriter.Dispose 已經變更為擲回有用的例外狀況。
Chameleon 結構描述由多個結構描述所包含時可以正確地複製
沒有目標命名空間的結構描述 (也稱為 Chameleon 結構描述，先前包括了結構描述的一般型別)，會在包含於其他 XSD 時採用匯入結構描述的目標命名空間。
如果兩個結構描述都在 XmlSchemaSet 中，並且都包含 Chameleon 結構描述，則 Chameleon 結構描述無法正確地複製至兩個結構描述。這會影響 XML 驗證。不正確的驗證可能會造成資料損毀。
複製作業現在如預期般運作。
XsdValidatingReader.MoveToNextAttribute 現在可以在呼叫 MoveToAttribute(Int32) 之後正確運作
XsdValidatingReader.MoveToAttribute(Int32) 中的 Bug 導致 MoveToNextAttribute 失敗，因為目前的屬性索引從未更新過。這使得多型無法與不同的 XsdReader 子類別搭配運作。
XsdValidatingReader.MoveToNextAttribute 現在可以在呼叫 MoveToAttribute(Int32) 之後正確運作。
XmlReader.ReadContentAs 不再忽略傳入的 IXmlNamespaceResolver
接受 IXmlNamespaceResolver 的 XmlReader.ReadContentAs 方法現在會使用 IXmlNamespaceResolver 參數做為命名空間解析程式。在過去則是忽略 IXmlNamespaceResolver 參數，並且使用 XmlReader 做為命名空間解析程式。
即使不曾呼叫來進行測試，Function-available XSLT 函式現在仍可運作
function-available 函式可用來判斷具有特定名稱的函式是否可供使用。在過去，如果 XSLT 中未呼叫函式，則 function-available 函式會永遠傳回 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 函式的有效傳回值。任何相依於 ID 值 null 的程式碼都將必須加以變更。
DocumentXPathNavigator 現在會正確報告 x:xmlns 屬性的本機名稱
DocumentXPathNavigator 先前會傳回空字串做為 x:xmlns 屬性的本機名稱。先前的行為可能會在特定情況下導致資料損毀，並造成無法使用 XSLT 來產生 XSLT。
本機名稱現在會正確傳回，進而啟用 XSLT、產生其他 XSLT 的程式碼或傳回 x:xmlns 用法的文件。
子樹上的 XsltReader 和 XmlReader 無法在一個 XML 項目上建立重複的命名空間宣告
使用 XsltReader 讀取 XSLT 時，如果 XmlReader 位於 XsltReader，則產生的 XML 項目會包含重複的命名空間宣告。這是無效的 XML，並且可能會對某些 XML 處理器造成問題。
這個先前的行為可能會導致資料損毀，並造成無法從 XmlReader 建立有效的 XML。