This post is about connecting to a WCF service from a client application. The key takeaways in this post relate to understanding endpoints and how to connect to them. We will explore adding service references from client applications. We will also show you how client applications can pass data into a WCF service.
The client is also capable of receiving return data from a WCF service call.
In this post, you will learn a few things:
How to write and debug a client application connecting to WCF services
How to access named endpoints inside of an app.config on the client
How to attach a service reference and generate type information to simplify client programming
How to run both the WCF service and the client using the debugging tools
Before we can connect from a client application, we need to look at the WCF services Mex endpoint. The client application will use this endpoint to retrieve type information about FlipCaseService.
We will now add the client project to the overall solution. Right mouse click on the solution and follow the menu below.
Adding a new project
Choose console application from the new Project dialog box. Provide a name as seen below.
Adding a console application
Note that our solution now has to projects. One for server and one for client.
Viewing solution Explorer
In order for the client to connect to the WCF service, we need to add a service reference. Right mouse click on the references I the client and choose Add Service reference.
Adding a service reference from the client
Although we already looked at the endpoint so that we knew how to connect to it, we can choose the Discover button as seen below. Because our client application is in the same solution as the WCF of service, this works. Note that we will provide a namespace name before clicking OK.
Connecting to a Mex endpoint
Adding the service reference also added two additional references as seen below.
Viewing the references that were added
Double-click on Program.cs to open the file to be edited.
The first red box below was about adding that using statements for the previous reference added. The second red box is the first line of code which will start the process of connecting to the WCF service. Notice the quotes are blank. Our WCF service offers three separate endpoints. The desired endpoint name is the one that gets typed into the quotes below in the second red box.
Adding some code
The five viewing the client’s app.config file, you can get the name of each of the three endpoints. We will arbitrarily use the endpoint that has basic HTTP binding.
Viewing the names of the endpoints
Paste in the name of the endpoint. Then add the remaining courage you see in the red box. This is the main routine for our client file Program.cs. You can double-click on Program.cs to open it so that you can edit it.
Wrapping up Program.cs
Notice in the red box below we made a slight edit. The variable sd is assigned the return value from FlipTheCase(). Notice that the original string being passed in is Bruno.
Writing the client-side code to consume Web services
After compiling the solution, you can begin by running the WCF service. Right mouse click on the Web service project and choose Debug/ Start new instance. This will load the WCF service into memory and make it available to the client application.
Starting the WCF service
Notice the WCF service is now up and running, as evidenced by the WCF test client application in the red box.
Viewing the WCF Client
We will now debug the client application by right mouse clicking on the client project in solution Explorer. Then choose Debug/Start new instance.
Starting the client
Notice below that the flipped case has appeared bRUNO.
This concludes explanation of how a client application can consume WCF Services. Although we chose a console application, you can also choose WPF or Winforms, and more.
In this post, you learned a few things:
My experience is that writing unit tests and having client and service created in the same test is a handy way to quickly and automatically test the full WCF-communication with all its layers between a client and a service. Testing non-GUI software through some GUI seems odd and unpractical, even as an example.
I agree that automating client side interactions with a WCF Service back-end makes sense. However, in order to properly understand how to automate and perform unit testing, you need a solid conceptual understanding of how to write hard-coded client applications by hand. Automating something without understanding the underpinnings is like memorizing a multiple choice exam without reading the questions.