WCF ServiceModel.CommunicationException when called internally - c#

I added the reference of an external wcf service to my project. I can consume this service normally, but trying to consume internally (on the same server as the service is exposed to) I am getting the error below:
System.ServiceModel.CommunicationException: Error in deserializing body of reply message for operation 'RETMALHA'. OperationFormatter encountered an invalid Message body. Expected to find node type 'Element' with name 'RETMALHARESPONSE' and namespace 'http://200.XXX.XXX.XX:81/'. Found node type 'Element' with name 'RETMALHARESPONSE' and namespace 'http://192.168.XXX.XXX:81/' ---> System.Runtime.Serialization.SerializationException: OperationFormatter encountered an invalid Message body. Expected to find node type 'Element' with name 'RETMALHARESPONSE' and namespace 'http://200.XXX.XXX.XX:81/'. Found node type 'Element' with name 'RETMALHARESPONSE' and namespace 'http://192.168.XXX.XXX:81/'
Given this message I manually manipulated the automatically generated "References.cs" file and changed the address of the Namespaces that had 200.XXX.XXX.XX:81 to 192.168.XXX.XXX:81. After this change internally began to work, but externally no longer works.
This service was not created by me, I am just consuming. And the application I'm developing will consume internally and externally.
Is there anything that I could make the client side flexible? Or do I have to talk to the service owner? What's wrong?

WCF‘s SOAP envelope needs to serialize and deserialize data as it is transmitted between the client-side and the server. This requires that for custom data types (data conventions), it is important to ensure that the data type has the same fully qualified name on both the client-side and the server-side, including its namespace attribute. In general, this values should be constant for a particular endpoint address (when we call the service by adding service reference), Please make sure you use the right service endpoint to add the service.
Feel free to let me know if there is anything I can help with.

Related

WebService error: the referenced element with ID '1' was not found in the document

What is the reason of this error in web-service method call?
The referenced element with ID '1' was not found in the document.
And what is the solution?
In my case, the mistake was that I use a wep-api URL as wcf URL. Instead of adding wcf service, I added WEB-Service reference and problem solved.
The serializations in WCF and WEB-API are different so this problem occured.

WCF Soap Services without Soap Action

I have an existing soap client who communicates with a soap service without using the soap action attribute. Now, we have recently substituted this soap service with a C# WCF Service which requires a soap action by default.
When I import the WSDL again, there is no problem. But, I don't want to regenerate the soap client because of backward compatible reasons. This afternoon I found an article with solves my problem: http://spikesoftware.azurewebsites.net/?p=151#comment-396784
The problem now is that my C# client can't invoke most of the soap actions. I can't find out the reason why this is not working anymore.
The error I received is the following:
Message:
System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]
: Error in deserializing body of request message for operation
'GetWorkshops'. OperationFormatter encountered an invalid Message
body. Expected to find node type 'Element' with the name
'GetWorkshops' and namespace 'http://tempuri.org/'. Found node type
'Element' with name 'GetWorkshops_V2' and namespace
'http://tempuri.org/'
The operation contract for these two methods like this:
[OperationContract(Action = "GetWorkshops", Name = "GetWorkshops")]
WorkshopResponse GetWorkshops(<some parameters>)
[OperationContract (Action = "GetWorkshops_V2", Name = "GetWorkshops_V2")]
WorkshopResponse_V2 GetWorkshopsV2(<some parameters>)
Can someone help me?
You can try out a couple of things,
Please use wsHttpBinding instead of basicHttpBinding
Generate a client proxy using svcutil

Windows 8 app refuses to connect to Azure service with a proxy running

I've got an app in the Windows 8 store that uses a WCF service hosted on Azure. When I use my proxy program, UltraSurf, the app fails to connect to the service with this error:
The content type text/html of the response message does not match the
content type of the binding (text/xml; charset=utf-8). If using a
custom encoder, be sure that the IsContentTypeSupported method is
implemented properly. The first 472 bytes of the response were:
'
The requested URL could not be retrieved
'.
The URL mentioned in the quote is the default 'can't find the page Url' that UltraSurf produces and so the error message is probably of no use. The question is, why/how does Ultrasurf block/get in the way of my connection?
Can anybody shed some light on what's going on and why it fails connect please?
Thanks!
Working without much information here, but I'd suspect that the problem is that the proxy is just being a little picky.
I believe that your error message basically says, "I'm expecting to get back 'text/xml' data, but what I see is 'text/html' data". That's probably not because it can actually see 'text/html' data coming back, but rather, because it's not seeing the content type header from the response telling it that it is xml data.
I don't know exactly how you implemented your WCF service, or what type of data it's set up to return, but you might want to ensure that you explicitly set the content type somewhere in your code before the return and see what happens. Something like:
Response.ContentType = "text/xml";
The only other thing that springs to mind is that your application might be picky about the content type for XML in general. There's a bit of, um... subtle difference... around whether the appropriate content type for XML is 'application/xml' or 'text/xml'. It's possible that your service is presenting the one that your proxy doesn't like?

Handle unknown soap message from WCF

I have a client generated using SVCUTIL from WSDL + XSD in C# .net console app. All fine but for some logical error handling purpose, client may receive a response message, which is not defined in WSDL hence deserialization & will fail but method does not throw exception but returns null.
Is there any generic way to handle this situation or I define a fault/error message xsd(for soap message returned by server) and in case of null response, handle/deserialize the message.
PS: My remote service can not throw a fault exception for logical errors.(yeah a bit of blockage there).
WSDL is contract. It is same like if you have two objects and defined interface between them. If the first object calls the operation on the second object it expects return value defined by interface. If we would use some non-strongly typed language the second object would be able to return different type of return value and the first object would fail because of unexpected error.
Programming languages have approach to solve this - in case of .NET you would use object type as return value and you would always have to manually investigate what type did you receive and how to handle the return value. In case of WCF we also have such high level type - System.ServiceModel.Channels.Message but you really don't want to use it because in such case you will have to build SOAP request manually and parse incoming responses manually.
As a side note in web services single request type has always single response type and zero or more error types (which are SOAP faults). If you have a service which returns different response types on single request type such service is not "valid" web service and cannot be described by WSDL. Because of that it also cannot be in strongly typed way provided by auto-generated WCF proxy.

WCF proxy generated from WSDL, proxy method returns null

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?
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.
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.

Categories

Resources