Last year, I wrote an introductory WCF article, "C# WCF: A Minimal Client and Server Using Visual Studio 2012". In this article, we explored how to create a simple WCF service, and how to communicate with it using either the WCF Test Client provided with Visual Studio, or via client code. Visual Studio conveniently takes care of much of the plumbing involved in getting client and server to communicate with each other.
In today's article, we will be creating another simple WCF service to learn about a limitation in the WCF Test Client that bit me just yesterday - an issue you'll no doubt come across when using the WCF Test Client to send a string parameter containing a backslash.
First, let us create a new WCF Service Library project:
Now, by default you will have a service called Service1 that exposes a simple method called GetData(). You can test this directly using the WCF Test Client. Press F5 to launch the WCF Test Client; then double-click on the GetData() method, enter a value for the value parameter, and press the Invoke button to see the result (just as we had done in "C# WCF: A Minimal Client and Server Using Visual Studio 2012":
Next, let's add a new method called Echo() to our IService1 interface, which is our Service Contract. This is what it should look like:
[ServiceContract]
public
interface
IService1
{
[OperationContract]
string
GetData(int
value);
[OperationContract]
string
Echo(string
text);
[OperationContract]
CompositeType
GetDataUsingDataContract(CompositeType
composite);
//
TODO: Add your service operations here
}
public
string
Echo(string
text)
{
return
text;
}
Nothing special there - the server echoes the input back to the client, much like we had done in "C# Network Programming: Echo Client/Server". Now, let's fire up the WCF Test Client again (F5) and test our new method:
With an input of "Brazil nuts", it worked fine. Now let's try a fictional domain username:
This time, instead of getting back the data we sent, we're getting a null! Why is that? Let's put a breakpoint in our Echo method and investigate:
Well, as you can see, the input itself is arriving as null, so there's nothing wrong with our logic. To investigate further, switch to the XML tab in the WCF Test Client, where you can actually see the underlying data that is being sent and received:
And even here, you'll see that a null is being sent. It turns out that the problem is that the WCF Test Client does not escape backslashes, so it will convert the whole input to null if it encounters an escape sequence it doesn't recognise (in our case \d); but it does work normally when you send a recognised escape sequence, such as \n:
So whenever you use the WCF Test Client, always escape slashes you actually intend to send as such:
You don't have to do this if you communicate with your WCF service in code, of course.
Note: while this may or may not be seen as limitation in the WCF Test Client (since it's technically allowing you to enter a raw string), it's pretty evil that it silently converts the input string to null when it fails to parse it correctly.
Thanks for reading, and I hope someone finds this useful! :)
This certainly has saved me a lot of time. Thanks.
ReplyDelete