Nouveautés de System.Xml
Les fonctionnalités System.Xml suivantes sont nouvelles dans le .NET Framework : méthodes XmlConvert pour prendre en charge la quatrième édition de W3C.
Nouvelles méthodes XmlConvert
De nouveaux membres de la classe XmlConvert permettent la validation de chaînes et de caractères spécifiques en tant que jetons XML particuliers ou données XML valides :
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);
Modifications importantes dans Visual Studio 2010
Les sections suivantes représentent les modifications importantes dans System.Xml :
Modification de NullRefenceExceptions dans les classes XML
La classe XslCompiledTransform pouvait lever une NullReferenceException lors du chargement d'une feuille de style.
XmlNode.InnerText pouvait lever une NullReferenceException.
La classe XmlValidatingReader pouvait lever une NullReferenceException lorsque certains arguments passés à son constructeur avaient la valeur Null.
Ces éléments ont été modifiés pour lever des exceptions plus utiles et faciliter le débogage du code.
XmlWriter.Dispose ne supprime plus toutes les exceptions
XmlWriter.Dispose supprimait auparavant toutes les exceptions (y compris celles qui ne devaient pas être interceptées, telles que OutOfMemoryException).XmlWriter.Dispose a été modifié pour lever des exceptions utiles.
Les schémas caméléons sont à présent correctement clonés lorsqu'ils sont contenus dans plusieurs schémas
Les schémas sans espace de noms cible (également appelés schémas caméléons, types communs auparavant inclus dans un schéma) prennent l'espace de noms cible du schéma d'importation lorsqu'ils sont inclus dans un autre XSD.
Si deux schémas étaient dans un XmlSchemaSet et que les deux incluaient le schéma caméléon, ce dernier n'était pas correctement cloné dans les deux schémas.La validation XML en était affectée.La validation incorrecte pouvait entraîner un endommagement des données.
Le clonage fonctionne à présent comme prévu.
XsdValidatingReader.MoveToNextAttribute fonctionne à présent correctement après un appel à MoveToAttribute(Int32)
Un bogue dans XsdValidatingReader.MoveToAttribute(Int32) provoquait l'échec de MoveToNextAttribute, car l'index d'attributs en cours n'était jamais mis à jour.Cela empêchait le polymorphisme de fonctionner avec différentes sous-classes de XsdReader.
XsdValidatingReader.MoveToNextAttribute fonctionnera à présent correctement après un appel à MoveToAttribute(Int32).
XmlReader.ReadContentAs n'ignore plus un IXmlNamespaceResolver passé
La méthode XmlReader.ReadContentAs qui accepte un IXmlNamespaceResolver utilisera maintenant le paramètre IXmlNamespaceResolver en tant que programme de résolution d'espace de noms.Auparavant, le paramètre IXmlNamespaceResolver était ignoré et XmlReader était utilisé pour le programme de résolution d'espace de noms.
La fonction XSLT function-available fonctionne maintenant même si la fonction à tester n'est jamais appelée
La fonction function-available permet de déterminer si une fonction avec un nom particulier est disponible pour être utilisée.Auparavant, si la fonction n'était pas appelée dans le XSLT, la fonction function-available retournait toujours la valeur False, même si la fonction était disponible.Cette même erreur a été corrigée dans MSXML3 SP1.
Les bogues de dépendance dans XmlSchemaSet ont été corrigés
XmlSchemaSet permet la compilation des schémas XSD.Ces schémas peuvent inclure d'autres schémas (A.xsd peut inclure B.xsd qui peut inclure C.xsd).La compilation de ces schémas entraîne la traversée du graphique de dépendance.Auparavant, lorsqu'un schéma du jeu était modifié et qu'un schéma dépendant était recompilé ou retraité, le graphique de dépendance des schémas n'était pas correctement traversé, ce qui aboutissait à des schémas compilés incohérents.
XmlReader.Create a retourné un lecteur qui a ignoré de façon incorrecte un espace blanc significatif
La validation XML reconnaît un mode de contenu mixte contenant du texte et un balisage XML.En mode mixte, tous les espaces blancs sont significatifs et doivent être signalés.Auparavant, le XsdValidatingReader signalait l'espace blanc significatif comme non significatif.
Le comportement précédent pouvait entraîner une perte de données lorsque les données étaient chargées dans un XmlDocument ou XDocument/XElement qui élimine les espaces blancs non significatifs par défaut.
Les XmlWriters de retour à la ligne ne respectaient pas NewLineHandling.None
Si vous avez créé un XmlWriter de retour à la ligne (un XmlWriter qui écrit dans un autre XmlWriter) et spécifié que le XmlWriter de retour à la ligne a NewLineHandling.None, lorsque vous avez utilisé la méthode WriteChars et que le contenu incluait /r/n, la sortie contenait /r/n/r/n (endommagement de données).Deux scénarios courants ont été affectés par ce comportement.
Lors de l'utilisation d'un XmlWriter existant créé à partir d'un XmlSerializer, puis du retour à la ligne de ce writer.Si l'utilisateur du XML généré ne tolérait pas les espaces blancs (par exemple, un service Web tiers), un comportement inattendu peut se produire.
Lors de l'utilisation d'un XmlWriter pour insérer un contenu dans un XmlDocument ou XDocument existant.Le comportement précédent ne vous laisserait pas normaliser correctement de nouvelles lignes sur un contenu ajouté au document.
Avec ce correctif, NewLineHandling.None a le comportement approprié pour un writer de retour à la ligne.
Dans le XmlWriter, les références d'entité ont été décomposées en entités deux fois dans les attributs XML
Si l'utilisateur a tenté d'écrire une entité dans un attribut xmlns ou dans un attribut xml:lang ou xml:space à l'aide de XmlWriter.WriteEntityRef, l'entité a été décomposée en entités deux fois dans la sortie, ce qui a endommagé les données.
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();
Sortie :
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
Attendu :
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
À présent, l'entité n'est pas décomposée en entités deux fois.
XNode.CreateReader retourne le BaseURI approprié
Si vous avez créé un objet XmlReader à partir d'une classe LINQ to XML avec CreateReader, le lecteur n'a pas retourné le BaseURI approprié tant que Read n'a pas été appelé au moins une fois.Par conséquent, le code dépendant de la valeur du BaseURI avant le premier appel à Read changera une fois Read appelé, directement à partir de votre code ou d'un autre appel, comme en passant le XmlReader à une autre méthode.
En utilisant XSLT avec LINQ to XML, la fonction ID XSLT retourne à présent la valeur appropriée
Si vous créez un XmlReader à partir d'une classe LINQ to XML à l'aide de la fonction CreateReader et que ce XmlReader est passé à un XSLT, toutes les instances de la fonction ID dans le XSLT retournaient auparavant la valeur Null.Null n'est pas une valeur de retour valide pour la fonction ID.Tout code qui dépend de la valeur Null de la fonction ID devra être modifié.
DocumentXPathNavigator indique à présent correctement le nom local de l'attribut x:xmlns
DocumentXPathNavigator retournait auparavant une chaîne vide pour le nom local de l'attribut x:xmlns.Le comportement précédent pouvait entraîner un endommagement des données et empêcher l'utilisation de XSLT pour générer des XSLT dans certaines circonstances.
Le nom local est à présent retourné correctement, ce qui active les XSLT, le code qui génère d'autres XSLT ou des documents qui retournent l'utilisation de x:xmlns.
XsltReader et XmlReader dans une sous-arborescence ne créent pas de déclarations d'espaces de noms dupliquées dans un élément XML
Lors de la lecture d'un XSLT avec un XsltReader, si un XmlReader était disposé sur le XsltReader, l'élément XML résultant contenait des déclarations d'espaces de noms dupliquées, qui sont des données XML non valides qui pourraient provoquer des problèmes avec certains processeurs XML.
Le comportement précédent pouvait entraîner un endommagement des données et empêcher la création de données XML valides à partir du XmlReader.
Voir aussi
Concepts
Nouveautés de .NET Framework 4
Nouveautés de Visual Studio 2010