Neues zu System.Xml
Die folgenden System.Xml-Funktionen sind in .NET Framework neu: XmlConvert-Methoden zur Unterstützung von W3C Edition 4.
Neue XmlConvert-Methoden
Damit bestimmte Zeichen und Zeichenfolgen als bestimmte XML-Token oder als gültiger XML-Code validiert werden, lassen neue Member der XmlConvert-Klasse Folgendes zu:
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);
Wichtige Änderungen in Visual Studio 2010
In den folgenden Abschnitten werden die wichtigen Änderungen in System.Xml beschrieben:
Geänderte NullRefenceExceptions in XML-Klassen
Beim Laden eines Stylesheets konnte die XslCompiledTransform-Klasse eine NullReferenceException auslösen.
XmlNode.InnerText konnte eine NullReferenceException auslösen.
Die XmlValidatingReader-Klasse konnte eine NullReferenceException auslösen, wenn einige Argumente des zugehörigen Konstruktors NULL waren.
Dies wurde so geändert, dass hilfreichere Ausnahmen ausgelöst werden, um das Debuggen von Code zu erleichtern.
XmlWriter.Dispose unterdrückt nicht mehr alle Ausnahmen
XmlWriter.Dispose hat früher alle Ausnahmen unterdrückt (so auch Ausnahmen, die nicht abgefangen werden sollen, z. B. eine OutOfMemoryException).XmlWriter.Dispose wurde so geändert, dass hilfreiche Ausnahmen ausgelöst werden.
Chamäleonschemas werden jetzt ordnungsgemäß geklont, wenn sie in mehreren Schemas enthalten sind
Schemas ohne Zielnamespace (auch als Chamäleonschemas bezeichnet, schlossen früher allgemeine Typen in ein Schema ein) übernehmen den Zielnamespace des importierenden Schemas, wenn sie in ein anderes XSD-Schema eingeschlossen werden.
Wenn sich in einem XmlSchemaSet zwei Schemas befanden und beide Schemas das Chamäleonschema enthielten, wurde das Chamäleonschema nicht ordnungsgemäß in die beiden Schemas geklont.Davon war die XML-Validierung betroffen.Durch die falsche Validierung konnten Daten beschädigt werden.
Das Klonen funktioniert jetzt erwartungsgemäß.
XsdValidatingReader.MoveToNextAttribute funktioniert jetzt nach einem Aufruf von MoveToAttribute(Int32) ordnungsgemäß
Ein Fehler in XsdValidatingReader.MoveToAttribute (Int32) bewirkte, dass bei MoveToNextAttribute ein Fehler auftrat, da der aktuelle Attributindex nie aktualisiert wurde.Dadurch konnte diese Polymorphie nicht mit anderen Unterklassen von XsdReader verwendet werden.
Jetzt funktioniert XsdValidatingReader.MoveToNextAttribute nach einem Aufruf von MoveToAttribute(Int32) ordnungsgemäß.
Ein übergebener IXmlNamespaceResolver-Parameter wird von der XmlReader.ReadContentAs-Methode nicht mehr ignoriert
Die XmlReader.ReadContentAs-Methode, die einen IXmlNamespaceResolver-Parameter akzeptiert, verwendet jetzt den IXmlNamespaceResolver-Parameter als Namespaceresolver.Zuvor wurde der IXmlNamespaceResolver-Parameter ignoriert, und XmlReader wurde für den Namespaceresolver verwendet.
Die function-available-XSLT-Funktion funktioniert jetzt auch dann, wenn die zu überprüfende Funktion nicht aufgerufen wird
Mithilfe der function-available-Funktion wird ermittelt, ob eine Funktion mit einem bestimmten Namen für die Verwendung verfügbar ist.Wenn die Funktion bisher nicht in XSLT aufgerufen wurde, gab die function-available-Funktion immer false zurück, auch wenn die Funktion verfügbar war.Dieser Fehler wurde in MSXML3 SP1 behoben.
Abhängigkeitsfehler in XmlSchemaSet wurden behoben
Mithilfe von XmlSchemaSet können XSD-Schemas kompiliert werden.Diese Schemas können andere Schemas enthalten (A.xsd kann B.xsd enthalten und B.xsd kann C.xsd enthalten).Beim Kompilieren eines dieser Schemas wird das Abhängigkeitsdiagramm durchlaufen.Wenn früher ein Schema in einer Gruppe geändert und ein abhängiges Schema erneut kompiliert oder verarbeitet wurde, wurde das Schemaabhängigkeitsdiagramm nicht ordnungsgemäß durchlaufen, wodurch die Schemas inkonsistent kompiliert wurden.
XmlReader.Create hat einen Reader zurückgegeben, der fälschlicherweise wichtige Leerstellen verworfen hat
Bei der XML-Validierung wird ein gemischter Inhaltsmodus mit Text und XML-Markup erkannt.Im gemischten Modus sind alle Leerstellen wichtig und müssen gemeldet werden.Früher hat der XsdValidatingReader wichtige Leerstellen als nicht wichtig gemeldet.
Das frühere Verhalten konnte dazu führen, dass Daten beim Laden in ein XmlDocument oder in ein XDocument/XElement, bei dem unwichtige Leerstellen standardmäßig entfernt werden, verloren gingen.
NewLineHandling.None wurde von Vorschub-XmlWriters nicht beachtet
Wenn Sie früher einen Vorschub-XmlWriter (ein XmlWriter, der in einen anderen XmlWriter schreibt) erstellt und festgelegt haben, dass der Vorschub-XmlWriter bei der Verwendung der WriteChars-Methode NewLineHandling.None aufweist und der Inhalt /r/n enthält, enthielt die Ausgabe /r/n/r/n (beschädigte Daten).Von diesem Verhalten waren zwei allgemeine Szenarien betroffen.
Bei der Verwendung eines vorhandenen XmlWriters, der aus einem XmlSerializer erstellt wurde, und beim anschließenden Umbrechen dieses Writers.Wenn der Consumer des generierten XML-Codes nicht leerstellentolerant war (beispielsweise der Webdienst eines Drittanbieters), konnte ein unerwartetes Verhalten auftreten.
Bei der Verwendung eines XmlWriters zum Einfügen von Inhalt in ein vorhandenes XmlDocument oder XDocument.Aufgrund des früheren Verhaltens konnten Zeilenvorschübe in Inhalt, der dem Dokument hinzugefügt wurde, nicht ordnungsgemäß normalisiert werden.
Bei dieser Korrektur weist NewLineHandling.None das richtige Verhalten für einen Vorschub-Writer auf.
Im XmlWriter wurden Entitätsverweise in XML-Attributen zweimal in Entitäten geändert
Wenn der Benutzer versuchte, eine Entität mit XmlWriter.WriteEntityRef in ein xmlns-Attribut oder in ein xml:lang- oder xml:space-Attribut zu schreiben, wurde die Entität in der Ausgabe zweimal in Entitäten geändert, und die Daten wurden beschädigt.
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();
Ausgabe:
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
Erwartet:
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
Jetzt wird die Entität nicht mehr zweimal in Entitäten geändert.
XNode.CreateReader gibt den richtigen BaseURI zurück
Wenn Sie früher mit CreateReader ein XmlReader-Objekt aus einer LINQ to XML-Klasse erstellt haben, hat der Reader den richtigen BaseURI erst zurückgegeben, wenn Read mindestens einmal aufgerufen wurde.Das führt dazu, dass Code, der vom Wert des BaseURI vor der Änderung durch den ersten Read-Aufruf nach dem direkten Aufruf durch Ihren Code oder durch einen anderen Aufruf von Read abhängt, den XmlReader gerne an eine andere Methode übergibt.
Wenn XSLT mit LINQ to XML verwendet wird, gibt die XSLT-ID-Funktion nun den richtigen Wert zurück
Wenn Sie früher mit der CreateReader-Funktion einen XmlReader aus einer LINQ to XML-Klasse erstellt haben und dieser XmlReader an XSLT übergeben wurde, haben alle Instanzen der ID-Funktion in XSLT NULL zurückgegeben.NULL ist kein gültiger Rückgabewert für die ID-Funktion.Code, der darauf angewiesen ist, dass der ID-Wert NULL ist, muss geändert werden.
DocumentXPathNavigator gibt nun den lokalen Namen des x:xmlns-Attributs richtig an
DocumentXPathNavigator hat früher für den lokalen Namen des x:xmlns-Attributs eine leere Zeichenfolge zurückgegeben.Das frühere Verhalten konnte dazu führen, dass Daten beschädigt wurden und dass XSLT unter bestimmten Umständen nicht zum Generieren von XSLTs verwendet wurde.
Der lokale Name wird nun ordnungsgemäß zurückgegeben und ermöglicht XSLTs, Code, der andere XSLTs generiert, oder Dokumenten, die zurückgeben, die Verwendung von x:xmlns.
XsltReader und XmlReader in einer Teilstruktur erstellen keine doppelte Namespacedeklarationen innerhalb eines XML-Elements
Wenn beim Lesen eines XSLT mit einem XsltReader ein XmlReader auf den XsltReader gelegt wurde, enthielt das resultierende XML-Element doppelte Namespacedeklarationen, was in XML unzulässig ist und bei einigen XML-Prozessoren zu Problemen führen kann.
Dieses frühere Verhalten konnte dazu führen, dass Daten beschädigt wurden und dass vom XmlReader kein gültiger XML-Code erstellt wurde.