I have a windows app to test connecting to a 3rd party web service.
I've created a service reference using the wsdl that was provided.
The way the web service will work is a 4 step process.
Method call to get session ID.
Method call to pass arguments
Method call to execute arguments.
Method call to get results.
Now here is the strange part:
I can make the first call no issue.
Calls 2 and 3 do not work from my . net appliaction.
I get the error:
Error in deserializing body of reply message for operation 'setArguments'. End element 'Body' from namespace 'http://www.w3.org/2003/05/soap-envelope' expected. Found element 'ns:setArgumentsResponse'
I am at a total loss with this.
What I've done.
I am capturing my post in Fiddler.
When I examine the body everything looks correct.
If I take the same response that I captured and post it in Fiddler it works.
I've tried the this in Python at it works.
Is there some obscure setting that I could possibly be missing in my application?
My findings in step 1 should prove that I am creating a valid request. Could . NET possibly be choking on the response?
Any suggestions would be appreciated.
FYI:
binding="customBinding"
I've also tried basicBinding and got the same results.
EDIT:
I just wrapped a try/catch around each method and when I call method 4 I get a result. So the error must be on the response. Right?
Issues appears to be that I am consuming a Java web service.
I originally added it as a Service Reference which is causing my serialization errors on the response.
I removed this reference and re-added a Web Reference and it appears to be working without the serialization error.
Related
I've been searching for hours in stackoverflow and google but could not make this work:
I have a server that I need to call through a REST API.
It has an endpoint that I need to invoke through a GET method and I need to pass a body within the request. I do not have access to the person who developed the server, and I just need to invoke this.
I know a GET call with body is against the standard, but I have to live with it as the server is currently expecting it.
It works perfectly well in postman, but I cannot make it work in a .net framework 4.7.2 app.
Here's my postman request:
When I run this in .net it either gets a protocol violation (image below) or it never gets a response and it gets stuck at _lient.SendAsync(...) (second image below).
Gets stuck:
Any help is greatly appreciated. Thanks
Currently, our ASP.NET Core 3.1 web api's error handling sends everything to our error controller using app.UseExceptionHandling('/error'). This controller logs the error and sends the error response our clients expect. Unfortunately, our logs contain each error twice because Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware logs the error before our error controller. How can we completely remove/replace Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware such that we (a) log the error only once and (b) completely replaces the response with our content?
We decided to use app.UseExceptionHandling('/error') over app.Use<CustomMiddlewareErrorHandler>() because changing the content in middleware always produced the "response already started" error that we never see when we use the error controller. I've found tutorials that advice testing whether the response has already started, but we always want to replace it. I suppose we need to flush the response or something like that.
Can someone point me to a practical example that (a) prevents double logging and (b) allows me to completely replace the response after an error?
I've discovered something peculiar that's been going on for the past 2 days.
I'm returning back custom JSON message in my Web API 2.0. E.g. when there's been an Unauthorized Response (HttpStatusCode 401)..it's only returning back the HttpStatusCode and NOT the JSON.
Simply put, anything apart from a HTTP Status Code 200 is NOT returning back the custom JSON that I've explicitly put in my ActionHandlers to return back.
This has happened recently, in the past 2 days. I've tested my code locally and I'm getting the expected output I need..the custom JSON error messages but as soon as I publish to one of my slots whether it be production or dev..only HttpStatus Codes are being returned.
Can anyone verify this for me? I need a way to sort this issue out or atleast have Azure take a look at this and tell me what to do. I suspect it's been an Azure update which I'm unaware of.
Probably some kind of customErrors logic kicks in when you are remotely testing your site. Those logics are usually disabled when browsing locally.
Check your configuration. Under IIS, there is also the httpErrors configuration which may interfere.
And have you set TrySkipIisCustomErrors to true when your code yields an error responses?
Ok, so I've figured out the issue.
Upgraded Visual Studio to 2015 to get the .NET Framework to use 4.6.
Changed all of my projects in the solution to point to 4.6, re-compiled, published and finally tested.
Errors are returning back JSON now too.
IMO, Azure could've atleast sent us an update. Anyways, posting this answer so hopefully anyone else using Web Api can easily forgo this issue.
I'm creating an API using ASP.NET Web API 2. Everything looks okay but in some cases, after getting an error 400, all the next requests return that same error 400 reponse even if the requests are different.
If I restart IIS, redeploy the API or just changing one space in web.config, the request works fine until I get another error 400 somewhere and the problem starts again.
It looks the error 400 response is cached somehow...
Did anyone have this problem and know how to fix it?
I found solutions on stack overflow may b this can help you.
Configure IIS Express
I was having a single shared static DbContext instance.
I changed to one instance of DbContext for each of my scopes and got rid of the static DbContext and instead create and dispose of it after each SaveChanges(Async) call.
Now everything works fine. Hope it helps.
I have a Rest Service in Visual Studio (C#). Initially it was working . But When I add a new Rest method, solution build is successful. But when we try to call the old REST methods in the project (for example POST) it is giving me 500 internal server error.
In firebug this what I found:
XML Parsing Error: no element found Location:
moz-nullprincipal:{73793b55-dcc3-45d3-ae2c-eaeb48dfe0f8} Line Number
1, Column 1:
But if I remove my newly added Rest service method, everything works fine.
Can anyone help me out?
Probably an interface mismatch between the client and the server. Did you rebuild both the client and the server with the new method definitions?