"Antwort ist null" oder "Antwort enthält null" oder "Anfrage ist null" oder "Anfrage enthält null" bedeutet fast immer, dass Sie eine Namensraum-Nichtübereinstimmung haben. Zum Beispiel kann die Antwort enthalten:
%Vor%sollte aber tatsächlich
sein %Vor%In diesem Fall wird null empfangen.
Ich hatte das gleiche Problem, und wie vorgeschlagen, das Namespace-Problem war die Ursache. Meine Proxy-Klasse hat jedoch verschachtelte Klassen und lange Kette von geschachtelten Namespace.
Es war verwirrend, den richtigen Namespace zu identifizieren, der in Cs-Code für die Proxy-Klasse angewendet werden sollte. Hier beschreibe ich, wie man den Namespace ermittelt, der im Client-Proxy aktualisiert werden muss.
Was ich getan habe, war die Anfrage in der ClientMessageInspector-Klasse abzufangen, AfterReceiveReply-Methode (Aktiviert die Inspektion oder Änderung einer Nachricht, nachdem eine Antwortnachricht empfangen wurde, aber bevor sie an die Clientanwendung zurückgegeben wurde.) Verifizierte den Namespace des Objekts Zurückgeben von NULL in Antwort, indem XMLDocument verwendet. Ich habe die Proxy-Klasse mit dem aus XML bezogenen Namespace aktualisiert. Nachdem die Änderungen vorgenommen wurden, waren die Objekte als Antwort nicht null.
%Vor%Der einzige Grund, an den ich denken kann, ist ein Vertragskonflikt. Obwohl es seltsam ist, wenn kein Validierungsfehler ausgelöst wird. Verwenden Sie einen Client, der aus der richtigen WSDL generiert wurde? Ist es ein WCF-Client oder ein SOAP-Server? Die erste Validierung ist, ich bin sicher, aber Schema-Mismatches können durch letztere schlüpfen.
Jedes Mal, wenn mir das passiert, muss ich meine Service-Referenzen aktualisieren. Probieren Sie das aus und lassen Sie mich wissen, was passiert:)
Es wurde gelöst ... oder es gibt zumindest eine Problemumgehung. Im Java-Code sollten die @ XmlElementRefs und @ XmlElementRef @ XmlElements bzw. @ XmlElement sein (und auch das "type" -Attribut benötigt ein "name" -Attribut).
Ich vermute, wenn ich dies als eine neue Frage mit einem Java-Tag sowie C # und Web-Services gepostet hätte, hätte ein falkenäugiger Stackoverflower diesen Schuljungenfehler entdeckt.
Ich hatte ein ähnliches Problem, das ich gelöst habe, indem ich den Order-Wert in der Reference.cs überprüft habe. [System.Xml.Serialization.XmlElementAttribute (Order = 0)]
Die Reihenfolge der Rückgabeparameter hat sich geändert, aber das Aktualisieren meiner Service-Referenz in Visual Studio hat den Wert "Order" nicht geändert.
Überprüfen Sie, ob die in Fiddler / SoapUI zurückgegebenen Parameter mit denen in der von Ihnen generierten Klasse übereinstimmen.
Ich hatte einen ähnlichen Fall, wo ich einen Client über SVCUTIL / Service Reference von VS erstellt habe. Die Antwort wurde erfolgreich mit korrekten Daten empfangen (bestätigt mit der Methode IClientMessageInspector.AfterReceiveReply), die Werte auf Objektebene wurden jedoch nicht ausgefüllt. Es gab keine Deserialisierungsfehler (bestätigt über die Ausgabe von system.diagnostics)
Das Problem war zweifach:
1) Bestimmte Objekte wurden genau wie ihre Typen benannt, hatten jedoch unterschiedliche Namensräume von ihren Typen. Dies scheint den Proxy-Generator verwirrt zu haben, indem er den Namespace-Parameter (in der Annotation System.Xml.Serialization.XmlElementAttribute) der Klasse dem Objekt
zugewiesen hat2) Der Befehlsparameter (in der Annotation System.Xml.Serialization.XmlElementAttribute) der Eigenschaften war nicht erforderlich, und auch der Namespace-Parameter fehlte
so aus: [System.Xml.Serialization.XmlElementAttribute (IsNullable = true, Order = 0)]
an: [System.Xml.Serialization.XmlElementAttribute (IsNullable = true, Namespace="http://www.whathevernamespaceiscorrect.com"]]
Im generierten Proxy musste ich also den Namespace der Klasse auf den im Typ angegebenen Wert fixieren und den order-Parameter durch den Namespace-Parameter ersetzen, der ihn entsprechend dem wsdl
auf den richtigen Namespace einstelltTags und Links c# web-services