I've a portable class library and I need to consume soap web service within it-I'm using .NET Framework 4.5 and visual studio 2012-.. I added a service reference to it and I'm using it by creating a client and using event handler to use it's operations. But it returns this exception:
The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.
I've noticed that client configuration file is empty.I wanted to know how t consume this service
Your best bet would be to use Fiddler to capture request - response pair and start working from there. First thing you want to see is actual response and not .NET message, check what status code is returned. That should be enough to get you on the right track.
Related
I'm writing an application using Visual Studio 2010 that needs to communicate with a remote web service. Because the amount of data being submitted is potentially large, (up to 100MB), the service's documentation says that the request message must be sent using GZIP HTTP compression.
My question is how to do that, given that I'm just calling a method on the proxy object that Visual Studio generated, and not actually performing the POST myself? In other words, since there isn't a "request" anywhere in my code to GZIP, how can I tell WCF to do it for me?
I've connected to the service by adding a service reference to my application using the WSDL provided, then invoking a method on the Visual Studio generated proxy to submit the request. An exception is thrown with the message "Request message must be sent using HTTP compression." (This is not unexpected, of course.)
Is there an attribute within the web.config settings that define the WCF service that will cause WCF to GZIP the request before sending it to the remote host?
Note: I've spent significant time searching the web about this, but the problem is that most posts assume that it's the web service's response that needs to be compressed. In my case, however, it's the request that's being sent from my client.
It seems like I have been able resolve this issue in a way that makes no sense to me from a "why does this even exist" way.
First, I was working on the same task as you: trying to use proxy objects to create a web request, and ended up running into the same issue being unable to compress the client object.
The resolution I ended up with was manually creating an XDocument object (XmlDocument would work as well) which has the same structure as the required SOAP XML, and then used the (already) populated proxy object to populate the necessary XML values in the string of SOAP XML.
From there I made a HttpWebRequest object and added the appropriate headers to the request. One of the headers was for compression. Executing the code resulted in getting an entirely different, non-compression related, error.
You can see my solution for the HttpWebRequest here: Compress a HttpWebRequest using gzip
It seems silly that it isn't easy to do through this the proxy object; however, it may be that the third-party did not expose what is necessary in order to add properties to the request header and either a.) they don't know or b.) they don't care, but that's what we have to work with, unfortunately.
I had to figure something out as I am on a deadline, but I hope this helps you out as well.
Have you tried adding <binaryMessageEncoding /> to the <customBinding /> element? I think we are working on similar tasks and I am also receiving the above FaultException. Two other SO topics led me down asking this question. It's something that makes sense, as I'm also not making a WebRequest through the code, but calling the service through the Service Reference created when I imported the WSDL provided by the third-party.
WCF custom binding for compression (a code-based approach)
and
WCF client endpoint compression (a configuration-based approach)
Let me know if you have any success with the above approaches.
Edit
An answer in the following thread indicates that unless you have control over the web service and the client, it might be something that can be done.
Using compression with C# webservice client in Visual Studio 2010
Edit #2
I think a few folks have been able to make progress in compressing a third-party service request using GZip. Please check out this post: Getting error for content mismtach while consuming client web service.
That post helped me get rid of the error message I was receiving (which was telling me that the request must be made using HTTP compression). I hope it helps you as well.
The request message must be sent using HTTP compression (RFC 1952 - GZIP).
I have a WCF web service written in .NET 4.5 which is working fine.
The client I am using to call it (a SQL CLR stored procedure) has to use .NET 2 because it's for a Sql Server (2005).
When I test the web service using the built in WCF test client, everything works fine. Likewise, if I build a client using .NET 3+ with svcutil.exe it also works.
However, since I have to use .NET 2 the only solution I found was to use wsdl.exe to generate the client (original question) - which it did successfully, except I haven't manage to get it working.
I get the error The message with Action 'action removed' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).
I found this question, however it recommends looking into the EndpointDispatcher class which I'm not using since I'm on .NET 2.0.
As far as I know all of my namespaces are the same - yet still no luck. I have also tried using the service trace utility but it doesn't seem to show me anything useful.
Is it even possible to use a client made in this manner with a service this way? Or are the endpoints permanently incompatible?
I ended up regenerating my client with wsdl on the off chance I'd changed something, turns out I had. The client updated my namespaces and everything worked from that point on.
Recently a couple of WCF services have been introduced to our company's API.
There are sample implementations for Windows that make use of proxy codes generated by Visual Studio 2010 (either full WCF client or Silverlight code). All looking nice.
Then I figured out that it is also possible to let Studio generate a Webservices 2.0 client code proxy and what can I say:
It works just as fine as the WCF client
It also returns real objects, just like WCF
It is also using SOAP
What the heck is the difference/advantage of a native WCF client?
Please note that I'm especially interested in the CLIENT SIDE. The server side is a different story. The point is: why would I connect to a WCF server using WCF client code if Web Services client code works as good?
I can also ask with regards to MONO: WCF support in Mono is far from being perfect, while WebServices 2.0 are woking pretty well. So after fighting with WCF for a while I switched back to a WS 2.0 client code proxy and have not noticed any issues so far. Are there problems I will have to expect?
Flexibility.
Today, you're hitting that service via HTTP. Tomorrow, you might want to add some persistance and hit it via MSMQ. Using WCF that's a configuration change - using Webservice client code you're looking at a complete rewrite of that area of your code.
Another benefit is the ability to turn on tracing, message logging and diagnostics with nothing more than a configuration change.
See Administration and Diagnostics, which says
Diagnostics Features Provided by WCF
WCF provides the following diagnostics functionalities:
End-To-End tracing provides instrumentation data for troubleshooting an application without using a debugger. WCF outputs
traces for process milestones, as well as error messages. This can
include opening a channel factory or sending and receiving messages by
a service host. Tracing can be enabled for a running application to
monitor its progress. For more information, see the Tracing topic. To
understand how you can use tracing to debug your application, see the
Using Tracing to Troubleshoot Your Application topic.
Message logging allows you to see how messages look both before and after transmission. For more information, see the Message Logging
topic.
Event tracing writes events in the Event Log for any major issues. You can then use the Event Viewer to examine any abnormalities. For
more information, see the Event Logging topic.
Performance counters exposed through Performance Monitor enable you to monitor your application and system's health. For more
information, see the WCF Performance Counters topic.
If I have a server sitting somewhere that is not returning the correct information to a client that uses async methods to communicate with it, how do I debug this with soap?
I mean, atleast with rest I can just type in a web address inside a browser and see on the screen the xml response. But how is debugging usually done with soap?
Note, my client is c#/wpf and the server is java
Have look at soapUI. I usually use it to develop and debug soap based web services.
As already mentioned soapUI is great tool if you want to test communication manually. If you want to see what exactly happens between your application and the service use Fiddler.
I am trying to use a SOAP Web Service provided by a third party. I am having trouble getting the service to work correctly in .NET 3.5. I have added it as a web reference and all seems to go well. Problem is when I call the service all I get returned is a NULL object. I have worked with the provider and there service appears to be working correctly. He did mention:
"We are using Axis2 Document/Literal and support SOAP 1 and 2."
I am not exactly sure what that means as I am a semi-newbie to using Web Services. Do I need to change some configuration parameters or something in .NET to get this service to work correctly?
From my experience, web service interoperability isn't the magic it claims to be. Especially, between .NET and Java.
Axis2 is a Java web service "engine"
Document/Literal is a style of writing a WSDL that results in a special SOAP appearance
SOAP 1 and 2 (you probably know) the message format and specific versions thereof
all I get returned is a NULL object
Is not much to start with, could you provide more information?
I would recommend, that you try to intercept the exchanged SOAP messages (you can use tcpmon) and check if they are valid. You would probably get an exception if the remote service can't handle your request so I guess your client as some trouble parsing the response. Additionally, you can use soapUI to generate example request to see what a valid request should look like.
Doc/lit (and at least SOAP 1) ought to work with WCF, but I'm not sure how the legacy (pre-.NET 3.0) web service client deals with that.
Did you, in Visual Studio, add a web reference or a service reference? If you added a web reference, you are not using WCF, which may be the reason it's not working. If this is the case, you should delete the web reference and see if adding a service reference instead helps.
It sounds like the proxy that you have generated (via add web reference) is not de-serializing the xml into the type you expect.
As wierob suggests the first thing I would do is trace the messages that you send to the service and the response you receive - that way you can examine the xml you can check that the proxy is creating a suitable request message and see whether the response does contain data that is not being de-serialized into the object you expect
As well as tcpmon you could use fiddler (from microsoft) to trace the traffic or the simplest would be to switch on the message tracing in WCF to log the request and response to files which could then you examined in the service trace viewer tool
With these kind of interoperability issues I find the best thing is to look at the message "on the wire" first - you may then have to tweak the wsdl so that the proxy gets generated correctly or hand craft the proxy yourself
If you post the wsdl and your proxy that might give us a clue as to the issues