2016-08-06 78 views
0

Ich erhalte die Fehlermeldung "Die maximale Anzahl der Namensntabellen Zeichenanzahl (16384) wurde beim Lesen von XML-Daten überschritten .... Zeile 3, Position 435. " bei einem Anruf zu einem kommerziellen SOAP-Webdienst. Die tatsächlich zurückgegebenen Daten überschreiten jedoch keinerlei Anzahl - es sind 2k absolut gültige XML-Daten und in Zeile 3 oder einer anderen Zeile ist kein Zeichen 435 vorhanden. Die Fehlermeldung macht keinen Sinn.. Net 4.6 Service-Referenzaufruf schlägt fehl mit "maximale Anzahl der Namensntabellen Zeichenanzahl"

Ich habe andere Fragen zu dieser Fehlermeldung auf Stackoverflow gesehen, aber sie sind in der Regel von der Art, wo der Fehler tatsächlich bedeutet, was es sagt, und die richtige Lösung ist, das Längenlimit in Frage zu erhöhen. Das ist hier nicht der Fall.

Hintergrund: Seit Jahren verwendet unsere Web-App den Webservice eines kommerziellen Anbieters, um Zahlungen zu verarbeiten. Und die WSDL/XSD-Spezifikation, die wir verwendet haben, um unsere Schnittstelle zu definieren, ist jetzt in vielen Versionen veraltet, funktioniert aber immer noch. Wir versuchen nun, ihre aktuelle WSDL und XSD zu verwenden, damit wir die neuesten Funktionen nutzen können. Aber sobald ich die Service-Schnittstelle aus dem modernen Layout neu generiere, funktioniert es nicht mehr - es erzeugt den Fehler "Maximale Nametable-Zeichenanzahl", der in eine XML-Parsing-Ausnahme eingeschlossen ist.

Nach stundenlangem Kampf gelang es mir, eine IClientMessageInspector-Klasse an den Dienst anzuhängen, damit ich den Inhalt der SOAP-Anfragen und -Antworten protokollieren konnte. Sie könnten sich vorstellen, wie verwirrt ich war, als ich sah, dass die Antwort keine schlecht formatierte Serverfehlermeldung war, die nicht geparst werden konnte, sondern eine kurze und einfache XML-Antwort, die auf eine erfolgreiche Transaktion hindeutete Empfang.

Meine letzte verzweifelte Hoffnung war, das Disassembly-Debugging von Visual Studio zu verwenden, um zu dem Ort zu gelangen, an dem der Fehler ausgelöst wurde, und zu sehen, welche Art von Eingabe fehlgeschlagen ist, aber leider überspringt Visual Studio das Code - es verweigert den Schritt, obwohl "eigener Code" ausgeschaltet ist.

Der Stack-Trace der inneren Ausnahme lautet:

at System.Xml.XmlExceptionHelper.ThrowXmlException(XmlDictionaryReader reader, String res, String arg1, String arg2, String arg3) 
at System.Xml.XmlExceptionHelper.ThrowMaxNameTableCharCountExceeded(XmlDictionaryReader reader, Int32 maxNameTableCharCount) 
at System.Xml.XmlBaseReader.QuotaNameTable.Add(Int32 charCount) 
at System.Xml.XmlBaseReader.QuotaNameTable.Add(String value) 
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderITransactionProcessor.InitIDs() 
at System.Xml.Serialization.XmlSerializationReader.Init(XmlReader r, XmlDeserializationEvents events, String encodingStyle, TempAssembly tempAssembly) 
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events) 

Diese in einem InvalidOperationException gewickelt ist, die "Es ist ein Fehler in XML-Dokument (3, 436)" mit dieser Spur sagt:

at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events) 
at System.ServiceModel.Dispatcher.XmlSerializerOperationFormatter.DeserializeBody(XmlDictionaryReader reader, MessageVersion version, XmlSerializer serializer, MessagePartDescription returnPart, MessagePartDescriptionCollection bodyParts, Object[] parameters, Boolean isRequest) 

und das ist wiederum in eine CommunicationException gehüllt sagen "Fehler beim Deserialisieren Körper der Antwortnachricht für die Operation 'xxxx'."

Ich habe keine Ahnung, wie es weiter geht. Ich kann die Fehlermeldung nicht mit etwas verbinden, das für die Analyse zugänglich ist. Was könnte das verursachen?

+0

Haben Sie versucht, den Wert zu erhöhen für die MaxNameTableCharCount in ReaderQuotas auf der Bindung? Es kann bis zu einem Int32.Max dauern. Die neuere Version des Diensts möglicherweise Methoden und Namespaces hinzugefügt, die dieses Problem verursacht (nur eine semi-basierte Schätzung). – Tim

+0

Werde versuchen, Montag ... wenn das eine Lösung ist, muss ich mich wirklich fragen, was zum Teufel es tatsächlich analysiert.Ich habe es auf Grund von Aussagen, die aus irgendeinem Grund auf den Server gesetzt werden mussten, zunächst aufgeschoben, obwohl ich denke, dass das nur zählt, wenn beide Enden .net-Klassen sind, und ich hoffe, dass das kein Problem sein sollte mit generischer Vanille SOAP. –

+0

@Tim Okay, das hat tatsächlich funktioniert. Ich stieß es von 16k auf 64k und der Fehler ist nicht mehr. Das lässt mich immer noch wundern, was zum Teufel es dachte, es war Parsing, da weder die zurückgegebenen XML noch eine der Metadaten, die ich sehe, eine solche Position wie Position 3 345 hat, noch kann ich etwas finden, das über 16k verschiedene Elemente enthält es (das Xsd ist groß, aber die Gesamtzahl der Namen in ihm ist nur wie 4k). Vielleicht zählt es die Länge der Namen. Wie auch immer, wenn Sie Ihren Vorschlag als eine echte Antwort schreiben, werde ich Ihnen den Kredit geben. –

Antwort

1

die maxNameTableCharCount auf Client-Seite in der config erhöhen:

<readerQuotas maxDepth="32" 
       maxStringContentLength="5242880" 
       maxArrayLength="16384" 
       maxBytesPerRead="4096" 
       maxNameTableCharCount="5242880"/> 

Die Leser Kontingenteinstellungen gelten nur für den Client (oder Dienstleistung) - im Grunde welcher Seite ist, dass config.

Die Größe der XSDs kann, warum die erhöhte Größe notwendig ist - MSDN-Dokumentation ist nicht wirklich klar, was diese Eigenschaft des Fall ist, so ist dies eine halbe Vermutung :)

+0

Mann, MSDN-Dokumentation kann so ärgerlich sein, inspirierte diesen Blog-Post: https://supersonicman.wordpress.com/2016/08/06/pseudo-documentation/ –