WCF proxy generated from WSDL, proxy method returns null.

Question

I've generated a WCF proxy from a WSDL file, but now when I call the proxy methods, they return null. I've enabled message logging, and can see that the messages from the server are correctly returned.

I've checked the answer of this question, but in my case at least the name of the returned object was the same in the message and in the WSDL. I still believe the problem has to do with the WSDL file, since it is not fetched the usual way through the "?wsdl" URL (it is a 3rd party webservice), but was given separately.

The return type of the method is just a string.

Has anyone else had similar problems, and what was the corresponding solution, if any? What is the most likely source of the problem?

Re-edit:

It is a RPC/Encoded web service. As written, I can see the SOAP response through message logging, but WCF seems not to be able to parse the information.

The message part of the response from the service looks like this:

<ns1:ServiceResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="the target namespace">
    <ns1:ReturnValue xsi:type="xsd:string">

However, when inspecting the outgoing message from my client, it's different:

<ns1:ServiceRequest soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="the target namespace">
    <RequestValue xsi:type="xsd:string" xmlns="">

So maybe the proxy expects the response to have the same namespace structure, and thus fails to parse it.

I've tried to change the type attribute to element in the wsdl message definitions, and adding some new elements in the types part of the wsdl definition, but then the svcutil chokes when generating the proxy, complaining that there's a clash between the inferred style document and specified style rpc.

From the WSDL specification, section 3.5:

If use is encoded, then each message part references an abstract type using the type attribute.

But then I'm a bit confused, since it doesn't seem to have been a problem in this question. What would be needed to make a similar change, with the restriction that it is a RPC/encoded service?

Answer 1

We have had something similar when using a WCF client against a WSDL from a Java web service.

Our problem was that we could not see the data that was coming back from the service, it looked like the data was missing.

However, when we looked at what was going over the wire, the data was there.

The problem was that the WSDL had many types that inherited from other types. By default we would only see the information in the base type.

The solution was to cast the object to the type we expected, then all the fields appeared.

Answer 2

You'll have to give specifics about the Java service in order to resolve this. However, I suspect that the Java service is using message parts defined with the type attribute. These do not conform to WS-I Basic Profile 1 because there is ambiguity about which namespace should be used for the elements of the message. Some services will use the namespace of the type, while others will (correctly) use the namespace of the web service itself.

Using the element attribute removes the ambiguity, and is therefore preferred.

Please post a snippet of the WSDL containing one of the messages you're having trouble with. When you then compare the definition of the message with what you're seeing on the wire, and then compare that to the details of the proxy class that's meant to consume the message, I believe you'll see what I mean. The proxy class is expecting one namespace, but on the wire, a different namespace is being used.