Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Las siguientes características de System.Xml son nuevas en los métodos .NET Framework: XmlConvert para admitir la cuarta edición de W3C.
Nuevos métodos XmlConvert
Los nuevos miembros de la clase XmlConvert permiten que se validen caracteres y cadenas específicos como tokens XML concretos o como XML válido:
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);
Cambios importantes en Visual Studio 2010
En las siguientes secciones se incluyen los cambios importantes de System.Xml:
Se ha cambiado la excepción NullRefenceExceptions en las clases relacionadas con XML
La clase XslCompiledTransform puede producir una excepción NullReferenceException al cargar una hoja de estilos.
XmlNode.InnerText puede producir una excepción NullReferenceException.
La clase XmlValidatingReader puede producir una excepción NullReferenceException cuando el valor de algunos argumentos en su constructor sea NULL.
Todo esto se ha cambiado para producir excepciones más útiles y facilitar la depuración del código.
El método XmlWriter.Dispose ya no suprime todas las excepciones
El método XmlWriter.Dispose anteriormente suprimía todas las excepciones (incluidas las excepciones que no se deben detectar, como OutOfMemoryException).El método XmlWriter.Dispose se ha cambiado para producir excepciones útiles.
Los esquemas camaleónicos se clonan correctamente cuando los incluyen varios esquemas
Los esquemas que no tienen un espacio de nombres de destino (también denominados esquemas camaleónicos y que anteriormente incluían tipos comunes en un esquema) toman el espacio de nombres de destino del esquema de importación cuando se incluyen en otro esquema XSD.
Si hubiera dos esquemas en una clase XmlSchemaSet y ambos esquemas incluyesen el esquema camaleónico, este último no se clonaría correctamente en ambos esquemas.La validación de XML se vio afectada por este hecho.El resultado de una validación incorrecta es el daño de los datos.
La clonación funciona ahora como era de esperar.
XsdValidatingReader.MoveToNextAttribute ya funciona correctamente después de una llamada al método MoveToAttribute(Int32)
Un error en XsdValidatingReader.MoveToAttribute(Int32) provocó el error de MoveToNextAttribute porque el índice del atributo actual nunca se actualizó.Esto impidió que funcionara el polimorfismo con distintas subclases de XsdReader.
XsdValidatingReader.MoveToNextAttribute funcionará ahora correctamente después de una llamada al método MoveToAttribute(Int32).
El método XmlReader.ReadContentAs ya no se ignora cuando se pasa en un objeto IXmlNamespaceResolver
El método XmlReader.ReadContentAs que acepta un objeto IXmlNamespaceResolver usará ahora el parámetro IXmlNamespaceResolver como la resolución de espacios de nombres.Previamente, el parámetro IXmlNamespaceResolver se ignoraba y XmlReader se usaba para la resolución de espacios de nombres.
La función XSLT function-available ahora funciona aunque nunca se llame a la función que se va a probar
La función function-available se usa para determinar si una función con un nombre determinado está disponible para su uso.Previamente, si no se llamaba a la función en la transformación XSLT, function-available siempre devolvía false, aunque la función estuviese disponible.Este mismo error se corrigió en MSXML3 SP1.
Se han corregido los errores de dependencia en la clase XmlSchemaSet
La clase XmlSchemaSet permite que se compilen esquemas XSD.Estos esquemas pueden incluir otros esquemas (A.xsd puede incluir B.xsd que puede incluir C.xsd).La compilación de cualquiera de estos esquemas provoca que se atraviese el gráfico de dependencias.Previamente, cuando se modificaba un esquema del conjunto y se volvía a compilar o procesar un esquema dependiente, el gráfico de dependencias de los esquemas no se atravesaba correctamente, dando lugar a esquemas compilados incoherentemente.
El método XmlReader.Create devolvió un lector que descartó incorrectamente espacio en blanco significativo
La validación de XML reconoce un modo de contenido mixto que contiene texto y marcado XML.En modo mixto, todo el espacio en blanco es significativo y se debe notificar.Anteriormente, el objeto XsdValidatingReader notificaba el espacio en blanco significativo como no significativo.
El comportamiento previo podía tener como resultado la pérdida de datos cuando estos se cargaban en una clase XmlDocument o en las clases XDocument o XElement que eliminan el espacio en blanco no significativo de forma predeterminada.
El ajuste de la clase XmlWriter no respetaba el objeto NewLineHandling.None
Si se creaba una clase XmlWriter encapsulada (una clase XmlWriter que escribe en otra clase XmlWriter) y se especificaba la clase XmlWriter encapsulada con el objeto NewLineHandling.None, cuando se usaba el método WriteChars y el contenido contenía /r/n, la salida contenía /r/n/r/n (daños en los datos).Existen dos escenarios comunes que se vieron afectados por este comportamiento.
Al usar una clase XmlWriter existente creada a partir de una clase XmlSerializer y, a continuación, encapsular ese sistema de escritura.Si el consumidor del XML generado no admitía el espacio en blanco (por ejemplo, un servicio Web de terceros), el comportamiento podía ser inesperado.
Al usar una clase XmlWriter para insertar contenido en una clase XmlDocument o en una clase XDocument existentes.El comportamiento previo no permitiría normalizar correctamente las nuevas líneas del contenido agregado al documento.
Con esta corrección, el comportamiento del objeto NewLineHandling.None es el correcto para un sistema de escritura de ajuste.
En la clase XmlWriter, se crearon dos entidades de las referencias de entidad en los atributos XML
Si el usuario intentaba escribir una entidad en un atributo xmlns o en los atributos xml:lang o xml:space con el método XmlWriter.WriteEntityRef, se creaban dos entidades de la entidad en la salida, dañando los datos.
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();
Salida:
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
Se esperaba:
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
Ahora, no se crean dos entidades de la entidad.
El método XNode.CreateReader devuelve el objeto BaseURI correcto
Si creaba una clase XmlReader a partir de una clase LINQ to XML mediante CreateReader, el lector no devolvía el BaseURI correcto hasta que se llamaba a Read al menos una vez.Como resultado, el código dependiente del valor de BaseURI antes de la primera llamada a Read cambiará después de llamar a Read, ya sea directamente desde el código o desde otra llamada, como si se pasase XmlReader a otro método.
Si se usa XSLT con LINQ to XML, la función XSLT ID devuelve ahora el valor correcto
Si se crea una clase XmlReader a partir de una clase LINQ to XML mediante la función CreateReader y esta clase XmlReader se pasa a una transformación XSLT, cualquier instancia de la función ID de la transformación XSLT anteriormente devolvía el valor NULL.NULL no es un valor devuelto válido para la función ID.Cualquier código que dependa del valor de ID, siendo este NULL, se deberá cambiar.
DocumentXPathNavigator notifica correctamente el nombre local del atributo x:xmlns
DocumentXPathNavigator anteriormente devolvía una cadena vacía para el nombre local del atributo x:xmlns.El comportamiento previo podía ocasionar daños en los datos y evitar el uso de XSLT para generar transformaciones XSLT en algunos casos.
El nombre local ahora se devuelve correctamente, habilitando transformaciones XSLT, código que genera otras transformaciones XSLT o documentos que devuelven el uso x:xmlns.
XsltReader y XmlReader en un subárbol no crean declaraciones de espacio de nombres duplicadas en un elemento XML
Si se coloca una clase XmlReader en el objeto XsltReader al leer una transformación XSLT con un objeto XsltReader, el elemento XML resultante contenía declaraciones de espacio de nombres duplicadas, que es un XML no válido y podría ocasionar problemas con algunos procesadores XML.
Este comportamiento previo podría provocar daños en los datos e impedir la creación de un XML válido a partir de la clase XmlReader.
Vea también
Conceptos
Novedades de Visual Studio 2010