Novità di System.Xml
Di seguito sono riportate le nuove funzionalità di System.Xml introdotte in .NET Framework: i metodi XmlConvert per supportare la quarta edizione di W3C.
Nuovi metodi XmlConvert
I nuovi membri della classe XmlConvert consentono la convalida di stringhe e caratteri specifici come particolari token XML o codice XML valido:
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);
Ultime modifiche in Visual Studio 2010
Nelle sezioni seguenti sono riportate le ultime modifiche in System.Xml:
Oggetti NullRefenceException modificati nelle classi correlate a XML
La classe XslCompiledTransform poteva generare un oggetto NullReferenceException durante il caricamento di un foglio di stile.
XmlNode.InnerText poteva generare un oggetto NullReferenceException.
La classe XmlValidatingReader poteva generare un oggetto NullReferenceException quando alcuni argomenti nel relativo costruttore erano null.
Questi oggetti sono stati modificati in modo da generare eccezioni più utili e semplificare il debug del codice.
XmlWriter.Dispose non elimina più tutte le eccezioni
In precedenza, XmlWriter.Dispose eliminava tutte le eccezioni, comprese quelle che non dovevano essere rilevate come, ad esempio, OutOfMemoryException.XmlWriter.Dispose è stato modificato in modo da generare eccezioni utili.
Gli schemi camaleonti vengono ora duplicati correttamente quando sono inclusi in più schemi
Gli schemi che non dispongono di uno spazio dei nomi di destinazione, denominati anche schemi camaleonti, e che in precedenza includevano i tipi comuni in uno schema, prendono lo spazio dei nomi di destinazione dello schema di importazione quando vengono inclusi in un altro schema XSD.
Se due schemi erano presenti in un oggetto XmlSchemaSet ed entrambi gli schemi includevano lo schema camaleonte, quest'ultimo non veniva duplicato correttamente in entrambi gli schemi,influenzando la convalida XML.La convalida non corretta poteva causare un danneggiamento dei dati.
La duplicazione ora funziona come previsto.
XsdValidatingReader.MoveToNextAttribute ora funziona correttamente dopo una chiamata a MoveToAttribute(Int32)
Un bug in XsdValidatingReader.MoveToAttribute(Int32) causava un errore in MoveToNextAttribute poiché l'indice dell'attributo corrente non veniva mai aggiornato,impedendo al polimorfismo di essere utilizzato con diverse sottoclassi di XsdReader.
XsdValidatingReader.MoveToNextAttribute ora funziona correttamente dopo una chiamata a MoveToAttribute(Int32).
XmlReader.ReadContentAs non ignora più un oggetto IXmlNamespaceResolver passato
Il metodo XmlReader.ReadContentAs che accetta un oggetto IXmlNamespaceResolver utilizza ora il parametro IXmlNamespaceResolver come resolver dello spazio dei nomi.In precedenza, il parametro IXmlNamespaceResolver veniva ignorato e veniva utilizzato XmlReader come resolver dello spazio dei nomi.
La funzione XSLT function-available ora funziona anche se la funzione da testare non viene mai chiamata
La funzione function-available viene utilizzata per determinare se una funzione con un nome specifico è disponibile per l'uso.In precedenza, se la funzione non veniva chiamata in XSLT, function-available restituiva sempre false, anche se la funzione era disponibile.Lo stesso errore è stato corretto in MSXML3 SP1.
I bug di dipendenza in XmlSchemaSet sono stati corretti
XmlSchemaSet consente la compilazione degli schemi XSD.Questi schemi possono includere altri schemi, ad esempio A.xsd può includere B.xsd che può includere C.xsd.La compilazione di uno di questi schemi causa l'attraversamento del grafico delle dipendenze.In precedenza, quando uno schema del set veniva modificato e uno schema dipendente veniva ricompilato o rielaborato, il grafico delle dipendenze degli schemi non veniva attraversato correttamente, determinando schemi compilati incoerenti.
XmlReader.Create restituiva un reader che eliminava gli spazi vuoti significativi in modo non corretto
La convalida XML riconosce una modalità a contenuti misti contenente testo e markup XML.In modalità mista, tutti gli spazi vuoti sono significativi e devono essere segnalati.In precedenza, XsdValidatingReader segnalava gli spazi vuoti significativi come non significativi.
Il comportamento precedente poteva causare una perdita di dati quando i dati venivano caricati in un oggetto XmlDocument o XDocument/XElement che rimuove gli spazi vuoti non significativi per impostazione predefinita.
Gli oggetti XmlWriter di wrapping non rispettavano NewLineHandling.None
Se veniva creato un oggetto XmlWriter di wrapping, ovvero un oggetto XmlWriter che scrive in un altro oggetto XmlWriter, e veniva specificato che l'oggetto XmlWriter di wrapping conteneva un oggetto NewLineHandling.None, quando veniva utilizzato il metodo WriteChars e il contenuto includeva /r/n, l'output includeva /r/n/r/n (danneggiamento dei dati).Esistono due scenari comuni interessati da questo comportamento.
Quando si utilizza un oggetto XmlWriter esistente creato da un oggetto XmlSerializer e successivamente si esegue il wrapping di tale writer.Se il consumer dell'XML generato non era tollerante agli spazi vuoti, ad esempio un servizio Web di terze parti, poteva verificarsi un comportamento imprevisto.
Quando si utilizza un oggetto XmlWriter per inserire il contenuto in un oggetto XmlDocument o XDocument esistente.Il comportamento precedente non consentiva di normalizzare correttamente le nuove righe nel contenuto aggiunto al documento.
Con questa correzione NewLineHandling.None utilizza il comportamento corretto per un writer di wrapping.
In XmlWriter i riferimenti alle entità venivano ripetuti due volte negli attributi XML
Se l'utente tentava di scrivere un'entità in un attributo xmlns oppure in un attributo xml:lang o xml:space utilizzando XmlWriter.WriteEntityRef, l'entità veniva ripetuta due volte nell'output danneggiando i dati.
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();
Output:
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
Previsto:
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
L'entità ora non viene ripetuta due volte.
XNode.CreateReader restituisce l'oggetto BaseURI corretto
Se veniva creato un oggetto XmlReader da una classe LINQ to XML utilizzando CreateReader, il reader restituiva l'oggetto BaseURI corretto solo se Read veniva chiamato almeno una volta.Di conseguenza, il codice che dipendeva dal valore di BaseURI prima della prima chiamata a Read veniva modificato dopo la chiamata a Read, sia direttamente dal codice che da un'altra chiamata, ad esempio passando XmlReader a un altro metodo.
La funzione ID XSLT restituisce ora il valore corretto se si utilizza XSLT con LINQ to XML
Se veniva creato un oggetto XmlReader da una classe LINQ to XML tramite la funzione CreateReader e l'oggetto XmlReader veniva passato a un oggetto XSLT, in precedenza qualsiasi istanza della funzione ID in XSLT restituiva null.Null non rappresenta un valore restituito valido per la funzione ID.Il codice che dipendeva dal valore di ID null doveva essere modificato.
DocumentXPathNavigator restituisce ora il nome locale corretto dell'attributo x:xmlns
In precedenza, DocumentXPathNavigator restituiva una stringa vuota per il nome locale dell'attributo x:xmlns.Il comportamento precedente poteva danneggiare i dati e impedire l'utilizzo di XSLT per generare oggetti XSLT in alcune circostanze.
Il nome locale viene ora restituito correttamente, consentendo l'utilizzo di oggetti XSLT, di codice che genera altri oggetti XSLT o di documenti che restituiscono l'utilizzo di x:xmlns.
XsltReader e XmlReader in una sottostruttura non creano dichiarazioni dello spazio dei nomi duplicate all'interno di un elemento XML
Quando un oggetto XSLT veniva letto con un oggetto XsltReader e quest'ultimo conteneva un oggetto XmlReader, l'elemento XML risultante conteneva dichiarazioni dello spazio dei nomi duplicate, generando codice XML non valido e causando problemi con alcuni processori XML.
Questo comportamento precedente poteva danneggiare i dati e impedire la creazione di codice XML valido tramite XmlReader.
Vedere anche
Concetti
Novità di .NET Framework versione 4