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.
Related
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.
I'm building out a simple C# application that integrates with a SOAP web service. I add the service reference to the appropriate WSDL and everything works out fine so far.
Occasionally, the server's firewall will respond with a 503 error before the request gets a chance to hit the web service. That 503 error also contains some HTML with an ID number (which changes each time) that I want to capture.
If I catch the exception, it doesn't give me the full message - just the re-formatted basic exception that says the server is too busy.
I tried the message inspectors suggestion from this post:
Intercept SOAP messages from and to a web service at the client
...and it gives me the outbound request, but it never hits the AfterReceiveReply call, so the response isn't captured.
I've also tried subscribing to all of the channel's major events (Faulted, Opening, Opened, UnknownMessageReceived, etc), and I've tried inspecting the channel when I catch the exception, but nothing seems to work.
Any thoughts or suggestions?
Why not just run fiddler on the machine your soap client is running on and intercept and inspect the traffic that way?
Turn on WCF Tracing. In particular, Message Logging.
It seems like disabling SOAPProcessing in the .config file may be a step in this direction, but I was unable to figure out how to enable this setting via code (and I cannot use a .config file in my final application because this is a plugin and the parent app's .config file is dynamically generated each launch).
I was able to work around this somewhat. In my situation, I had separate dev and production servers. The 503s errors were happening mostly on the production server (likely due to the firewall being sensitive about a different hostname in the API requests), so I ended up with a solution that duplicated the API requests and sent them over to the production server.
(This was okay, because the production server was not configured with anything that would be affected by any API requests that made it through the firewall. The requests would just be considered invalid.)
I did this by using message inspectors to generate the last outgoing request. Then for each outgoing request, I generated a new WebBrowser control, set the proper headers (SOAPAction and all that), re-injected the security credentials (the message inspector stripped them out at runtime), and then posted the request to the production server with that WebBrowser control. The WebBrowser instance's DocumentCompleted event let me dump the result and search for the ticket ID when appropriate.
Not exactly glamorous, but it works well.
I can usually test my web application on my PC. (In "production" it's on a web hosting server.) But now I have a callback page (.ashx) and am not sure how to proceed - How do I have my application receive the callback? Is there some way to have the callback page redirect to my PC? Some way to have my PC receive callbacks and specify the callback address as my IP (I can chose any callback url I want.)? Maybe some other way?
I don't need to actually attach it to the debugger, only to see the results.
If your ASHX file is in an ASP.NET Web application or website, you can host it locally with IIS or visual studio and then call it with Fiddler (www.fiddler2.net)
Using fiddler you can make calls to your ASHX and pass any payload required.
I don't know your network environment, but depending on how flexible it is, you could set up dyndns or a static domain so that your callbacks actually reach your PC.
I don't love it, but it's a logical solution. Then once you've got everything working properly, you update the domain in all of your call backs to point to production, and you should be ready to go.
We have a Win32 application that connects to a third party application to send some info to it. That application has a web service that we call its methods. One of its web methods is called GetDevices and when our application is calling it, it will fail to work and I have no idea what are the details of this failure. So we should write a small diagnosis application that can create some detailed log files to know what is going, send it to them to run it and then we may know what is going on with more detail. Now do you have any ideas what is a good way to write such a diagnosis application for this debugging purpose?
If this web service is using HTTP (either SOAP or REST) you can use Fiddler to snoop the HTTP traffic and see what's happening.
When web requests are made, the request (and response from the server) will show up in Fiddler, and you can use that to determine why it's not doing what you expect.
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.