O Que Há de Novo em System.Xml

Os seguintes recursos System.Xml são novos em .NET Framework: Métodos de XmlConvert para dar suporte a edição do W3C a quarta.

Novos métodos de XmlConvert

Os novos membros da classe de XmlConvert permitem caracteres específicos e as cadeias de caracteres a serem validados como tokens específicos de XML ou 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);

Alterações recentes no Visual Studio 2010

As seções a seguir são as últimas alterações em System.Xml:

NullRefenceExceptions alterado em classes XML relacionados

• A classe de XslCompiledTransform pode gerar um NullReferenceException ao carregar uma folha de estilo.

• XmlNode.InnerText pode gerar um NullReferenceException.

• A classe de XmlValidatingReader pode gerar um NullReferenceException quando alguns argumentos ao construtor não nulos.

Esses foram modificados para gerar as exceções mais úteis e facilitar para depurar o código.

Não XmlWriter.Dispose suprime todas as exceções

XmlWriter.Dispose suprimiu anteriormente todas as exceções (inclusive as exceções que não devem ser capturadas, como um OutOfMemoryException).XmlWriter.Dispose foi alterado para lançar exceções úteis.

Esquemas de camaleão clonados agora corretamente quando incluído por vários esquemas

Os esquemas que não têm um namespace de destino (também chamada de esquemas de camaleão, anteriormente tipos comuns incluídos em um esquema) levam ao namespace de destino do esquema importando quando são incluídos em outro XSD.

Se dois esquemas estivessem em um XmlSchemaSet e ambos os esquemas que incluíram o esquema de camaleão, o esquema de camaleão não foi clonado corretamente em ambos os esquemas.Isso afetou a validação XML.A validação incorreta pode haver corrompimento dos dados.

Clonar agora funciona conforme o esperado.

XsdValidatingReader.MoveToNextAttribute agora funciona corretamente após uma chamada a MoveToAttribute (Int32)

Um bug em XsdValidatingReader.MoveToAttribute (Int32) fez com que MoveToNextAttribute falha porque o índice do atributo atual nunca foi atualizado.Isso impediu que polimorfismo funcione com as subclasses diferentes de XsdReader.

XsdValidatingReader.MoveToNextAttribute funcionará agora corretamente após uma chamada a MoveToAttribute (Int32).

XmlReader.ReadContentAs ignora não passado em um IXmlNamespaceResolver

O método de XmlReader.ReadContentAs que aceita um IXmlNamespaceResolver usará agora o parâmetro de IXmlNamespaceResolver como o resolvedor de namespace.Anteriormente, o parâmetro de IXmlNamespaceResolver foi ignorado e XmlReader foi usado para o resolvedor de namespace.

A função function-available XSLT agora funciona mesmo se a função é chamada teste nunca

A função function-available é usada para determinar se uma função com um nome específico está disponível para uso.Anteriormente, se a função não foi chamado em um XSLT, false sempre retornado function-available, mesmo se a função estava disponível.Esse mesmo erro foi corrigido em MSXML3 SP1.

Os bug de dependência em XmlSchemaSet foram corrigidos

XmlSchemaSet permite que os esquemas XSD são compilados.Esses esquemas podem incluir outros esquemas (A.xsd pode incluir B.xsd que pode incluir C.xsd).Criar qualquer um destes esquemas faz com que o gráfico de dependências a ser atravessado.Anteriormente, quando um esquema no conjunto foi alterado, e um esquema dependente foi recompilado ou processado novamente, o gráfico de dependências dos esquemas não foi passado por corretamente, o que leva a esquemas criados inconsistentes.

XmlReader.Create retornou um leitor que rejeitasse incorretamente o espaço em branco significativo

A validação XML reconhece um modo de conteúdo misto que contém o texto e marcação XML.No modo misto, todo o espaço em branco é significativa e deve ser informado.Anteriormente, o XsdValidatingReader informou o espaço em branco significativo como não significativo.

O comportamento anterior poderia resultar na perda de dados quando os dados foram carregados em um XmlDocument ou a um XDocument/XElement que descascasse o espaço em branco não significativa por padrão.

Envolvendo XmlWriters não respeitou NewLineHandling.None

Se você criou um XmlWriter de encapsulamento (um XmlWriter que grava a outro XmlWriter) e o especificou que o XmlWriter de encapsulamento tem NewLineHandling.None, quando você usou o método de WriteChars, e o conteúdo continha /r/n, /r/n/r/n contido saída (corrupção de dados).Há dois cenários comuns que foram afetados por esse comportamento.

• Ao usar um XmlWriter existente criado de um XmlSerializer, e ao incluir o gravador.Se o consumidor do XML gerado não era o espaço em branco tolerante a falhas (por exemplo, um serviço Web de terceiros), poderá haver um comportamento inesperado.

• Ao usar um XmlWriter para inserir conteúdo em um XmlDocument ou em um XDocument existente.O comportamento anterior não o permite corretamente normalizar linhas no conteúdo adicionado ao documento.

Com essa correção, NewLineHandling.None tem comportamento correto para um gravador de encapsulamento.

No, XmlWriter as referências de entidade foi Definida duas vezes nos atributos XML

Se o usuário tentar gravar uma entidade em um atributo de xmlns ou em um XML: lang ou XML: o atributo de espaço usando o XmlWriter.WriteEntityRef, a entidade é definida duas vezes na saída, corrompendo os dados.

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();

Saída:

<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&amp;e;" \>

Esperado:

<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>

Agora, a entidade não é definida duas vezes em.

XNode.CreateReader retorna o BaseURI correto

Se você criou um objeto XmlReader de um LINQ à classe de XML que usa CreateReader, o leitor não retornou o BaseURI correto até que a leitura esteve chamada pelo menos uma vez.No, o código dependendo do valor de BaseURI primeiro antes da chamada de leitura é alterado após a leitura é chamado, diretamente no seu código ou de outra chamada, como passar o XmlReader para outro método.

Usando XSLT com o LINQ te o XML, a ID do XSLT agora retorna o valor correto

Se você criar um XmlReader de um LINQ à classe de XML usando a função de CreateReader, e esse XmlReader é passado para o XSLT, algumas instâncias da função da ID em zero anteriormente retornado XSLT.Nulo não é um valor de retorno válido para a função de ID.Qualquer código que depender do valor da ID que é zero precisará ser alterado.

DocumentXPathNavigator agora informa corretamente o nome local de x: atributo de xmlns

DocumentXPathNavigator retornou anteriormente uma cadeia de caracteres vazia para o nome local de x: atributo de xmlns.O comportamento anterior poderia causar corrompimento dos dados e evitar-la usando XSLT para gerar em determinadas circunstâncias XSLTs.

O nome local é retornado agora corretamente, habilitando XSLTs, código que gera o outro XSLTs, ou documentos que retornam o uso de x: xmlns.

XsltReader e XmlReader em uma subárvore não criam duplicados declarações de namespace de um elemento XML

Ao ler XSLT com um XsltReader, se um XmlReader é colocado em XsltReader, as instruções contidas duplicados elemento XML resultantes do namespace, que é XML inválido e pode causar problemas com alguns processadores XML.

Esse comportamento anterior poderia causar corrompimento dos dados e impedir a criação de XML válido do XmlReader.

Consulte também

Conceitos

O que há de novo no .NET Framework 4.5

Novidades no Visual Studio 2013

Outros recursos

Documentos e dados XML