I got an application that invokes a third party, this was working just fine but suddenly I can't invoke the service. I tried with Soap UI, with a web browser and with visual studio; I just can't reach the service. The weird part is that if telnet the service's url and port it will work. Something is listening there. I also thought about something other than a webservice listening there but the service creator provided proof that he's able to invoke the service in the very same URL that's giving me trouble. What am I missing?
Well, mistery solved, in case anyone comes across something similar to this I post what I found out.
Soap UI was not working because proxy settings, if I tell it bypass the proxy then everything was fine. Visual Studio gave a different error because third party changed the wsdl without previous notification. So it was two different errors and that's what was giving me hell.
Related
a service is having multiple services which are hosed and started successfully, when i am trying with WCFTESTCLIENT tool i am getting the error "unable to get the metadata of the service plese check the service is running and exposing metadata". what are the tools we can use to troubleshoot this kind of problems in WCF service.
please help .
In my case the cause of the problem is in hosting process.unfortunately i commented the line servicehostObject.open() method in OnStart method. we can check the hosting process by using " netstat -a " command in VS command prompt. i have checked with this command, and came to know that the address/port was not there.but other ports with tcp protocol was there and also in listening status. so concluded that service not yet hosted. then i checked my windows Service hosting programs onStart method by using debugger.lauch().
and finally got the issue problem and fixed successfully. the problem is simple :D
i commented the service open method. like below.
//servicehostObject .open();
but this mistake gave the opportunity to learn about tracing. yeah issues/problems only help us to learn more always.
while using wcftestclient try to give the exact address of the service.
localhost/ip address make sure on this mainly.
I have an application that users were complaining that it hangs when the user trys to perform a certain action. I found it that it is hanging in a web service call. The web service is running on a remote server. I can't figure out how to debug into the web service through VS when the code is on a remote server.
How do I find out in the web service where exactly the code is hanging?
If you don't have access to the source of the web service then you're not going to be able to "debug" it. If you want to try to externally debug it then you can create a page that sends various inputs to it (some that should work, some that should error out, etc). You can then access this page in a browser that has developer tools (I would recommend Firefox w/ Firebug or Google Chrome) and then look at how long the calls are taking. Google Chrome will show you how long it took to send the request, how long it waited, how long it took to receive, etc. If it IS the actually web service and you don't have access to it then it would be odd that you were responsible for fixing this issue. I have a feeling though, if this is a robust web service, you're going to find that you're either having a networking issue or your sending it some invalid input or something along those lines.
If you do have access to the source code then simply run the web service locally and point your local version of the application at the local version of the web service. Any breakpoints you put in the web service will hang the application and you will be able to step through it just like you can non-web-service code.
In your own code, take a look at what is going on with the web service call. e.g Does it throw a fault? Timeout? Does it ever return a successful response? If not, are you sending valid data?
If the web service call is successful but just slow, consider how you might make your application appear to be more responsive. One possibility is to use Asynchronous Programming.
I am building a Httphandler following these instructions here
It manipulates HTTP POST and HTTP GET. I have a client with two buttons two POST and GET.
After i've tested and happy everythings working I move it from localhost to IIS. Now when I do this I get an exception in the POST handler code.
How on earth can I debug this code line by line? I managed to do this awhile ago, I thought it was by attaching to process but I can't work it out. I can emulate GET just by typing address in browser, post im not sure about. I've tried telnetting and sending it from there but haven't had any luck.
Attach visual studio debugger to asp.net worker process. It must work that way. You must attach to right worker process that is running your app as there may be multiple instances of asp.net worker process.
I have a project where I have created web service proxy classes with wsdl.exe and then simply create an instance of that class (inherits System.Web.Services.Protocols.SoapHttpClientProtocol) and call the method that should send a SOAP message. I'm using Visual Studio 2008 if that matters. And I'm trying this in my development machine without access to actual web service that is located inside of customer's intranet. So, the sending will of course not succeed and I will not get any response back but all I would like to see is the exact content of SOAP messages this solution creates and tries to send. How do I see that?
Use fiddler.
Have a look at SOAPUI from eviware.com.
Its a free for personal use Java app. Among other things you can
set it up to run as a dummy test server. Just load up hte WSDL
and enter the dummy data.
In test server mode it will log your requests so you can see whats happening
inside the request message.
If you're Web service is accessed by clear text, non-SSL HTTP, you can just use a sniffer, like Wireshark, to see the data coming from and to your application. Wireshark can trace, filter and analyze wire data. I have used it do debug HTTP and other protocols many times, and it's a great tool to do this.
SOAP messages are simply XML data sent using the HTTP POST method. So you can for example install a local web server on your development machine, configure your web service to use some dummy URI on this server, and grab the network traffic with WireShark (AKA ethereal). The big advantage of this method is that it involves no coding.
Alternatively you can use an HTTP echo server that dumps its incoming traffic, like this one (found while googling "http echo server"):
You can intercept the call with tcpMon
I have a C# application that is a client to a web service. One of my requirements is to allow capturing the SOAP that I send, so that if there is a problem, I can either fix the bug, or demonstrate that the problem is in the service I am calling.
My WebReference proxy service class derives from System.Web.Services.Protocols.SoapHttpClientProtocol as usual. If I had a magic wand, I would make this base class implement an event OnPost that I could handle to write the SOAP into my logs and continue.
Short of running a packet sniffer like WireShark, is there an easy way to get this level of logging?
I think what you are looking for is addressed in this question:
Getting RAW Soap Data from a Web Reference Client running in ASP.net
It looks like a lot of code though.
If the application is running on your local box and the web service isn't doing anything funky, you can use Fiddler. Fire Up IE, run Fiddler, and you'll see your web service calls go through fiddler's proxy too.
I just used this this morning to do almost the same thing. I had to prove the data my web service was sending wasn't messed up.
To see this traffic in fiddler use the following code:
mySoapHttpClientProtocol.Url = mySoapHttpClientProtocol.Url.Replace("localhost", "localhost.fiddler");
Otherwise, Visual Studio's built in web server will bypass all proxies.
Take a look at SoapExtensions.
They are what you need.
For some reason Fiddler was not showing my local service calls when using the ASP.NET Development Server that comes with Visual Studio. To get around this I changed the web service Url at runtime to be the Fiddler port, just to capture the SOAP message.
You can do this from the Immediate window, for example:
myservice.Url = "localhost:8888" (or whatever port you have Fiddler on)
I used the SoapUI client to test responses.
Just "." add the address in your endpoint after "localhost".
like this:
<endpoint address="http://localhost.:8868/FEInvoice.asmx" binding="basicHttpBinding"
bindingConfiguration="FEInvoice_Test" contract="EInvoiceIntegration.FEInvoiceSoap"
name="FEInvoice_Test" />