I recently added a parameter to one of the method of a wcf. It was a string parameter.
The thing is that I didn't update the service reference on the client side but I was still able to call the wcf service .....
Wasn't it suppose to break?
The client side had no idea that you updated the reference, so it won't throw a compile time error.
The service defaulted the string to null when it wasn't passed since it wasn't there which is perfectly valid.
Related
I am trying to call an external web-service via some proxy code generated by Visual Studio (based on the WSDL from the service). The result object I get back is null, even though I can see that the service does actually return a SOAP message (I can see that in Fiddler).
It appears that the SOAP message is not able to be deserialized by the code generated by Visual Studio. I have read that this can be due to a mismatch between what the service's WSDL tells us what to expect, and what the service actually returns.
Is it possible to get the deserialization code to report what the problem is, throw an exception, or something, instead of just silently returning null?
Thanks.
I'm not sure about the debugging, but one approach you can try is to create a simple web service which returns the structure you're expecting. Then you can compare the output from this service with the actual service to see if you see any problems.
I've added in the service reference an url like this: "https://example.com/cars?wsdl"
Everything works fine, I can access the methods from that soap and compile the project without errors.
When I call a method the endpoint address is https://example.com/cars (I've notice this with the debugger) on this page is only a fault error and every method I call it returns the fault error.
Why the service reference doesn't see the parameter "?wsdl" ?
Thanks!
Your fault message is probably coming from the service itself. The ?wsdl at the end just has information about your service. Put a try catch in the method that you're calling on the service layer.
The problem was solved by using xml request.
http://www.terminally-incoherent.com/blog/2008/05/05/send-a-https-post-request-with-c/
The error seems to be from the service itself.
I've debated at times what to exactly send back if I create a WCF service to clients consuming my web service. Usually I return custom DTOs and in that DTO I have a property called Success (bool) and also a couple property strings for errors that can be checked if Success is false.
But the client has to know (tightly coupled) about that DTO type in order to make the method call because it returns a DTO of x type.
I know I do want to return an object ...because I want to include the flag success and also always provide information if failed. But then should I return some type of Interface?
I'm not quite sure what is best to returned if you want your service to be able to be consumed by ANY .net client application.
If you have a server side error of a type which will require the caller to handle then you should wrap the error in a SOAP fault message.
This is the standard and intended way to pass error information back to your caller.
To pass a success/failure flag is kind of an anti-pattern, as you are forcing your consumers to interrogate the response object to know if there has been a failure.
In WCF, if you throw an exception in the service operation then WCF will automatically create the SOAP fault wrapper for you. This gives you an interoperable way to pass exception details back to your callers.
If the client is also a .NET application, I'd probably just thrown an exception.
Hi everyone let me explain this issue:
Background:
I have two web applications
The first one exposes some web services (server_wapp).
The second one consumes them (client_wapp).
I added a new web service to the server application that takes two strings as parameters, and it work OK using it directly form the .asmx page (new_ws).
Problem:
When I call the new_ws from the client_wapp all the parameters have their right content, but when the method is executed in the server_wapp, one of its parameters is passed as null.
Somthing link this:
In client_wapp I have server_wapp.new_ws("string1", "string2") and it gets executed in server_wapp as new_ws("string1", null).
I already rebuilt both web applications, but the problem remains.
Any ideas/comments?
Thanks in advance!
Update the link to server_wapp so that the proxy source code will be re-generated. WebService is usually used by adding reference to webservice url, and everytime you do some modifications in the webservice, its should be updated.
I have a versioning issue with a WCF service contract in which one of the many endpoints which are called for the operation is missing one method from the contract.
My question is, how can I make sure the command is available on the client before attempting to call it?
I tried:
foreach (var od in proxy.Endpoint.Contract.Operations)
{
if (od.Name == "MyMethodName")
{
hasMethod = true;
break;
}
}
Unfortunately, this is using the contract from the calling app and does not actually describe the implementations on the endpoint itself. As a result, it returns true even though the endpoint has failed to implement the command.
You'll never actually know until you try it. What you have is a proxy of the implemented contract, but what is on the server side could have changed since you created/generated it.
Assuming it's an http/httpws implementation I suppose you could call and check the service reference and download the wsdl file. That will tell you what methods etc are supported. The problem you're going to have is that even though the name of the method maybe the same, you'll also have to check the return type and parameters to really be sure that it's the same method and that you can call it with the proxy you currently have.
Here is a link on versioning in WCF:
http://msdn.microsoft.com/en-us/library/ms731060.aspx
Here is a link on versioning best practices for WCF:
Best practices for versioning your services with WCF?