Previous posts in this series:

Working with WCF: Part One – Introduction and Your First Service

Working with WCF: Part Two – Your First Host and A Bit About Configuration

Working with WCF: Part Three – Connecting To Your Service With A Client pt. 1

In my previous post in this series I outlined two of the three most common ways to create proxies for WCF services. The first technique as was to use the “Add Service Reference…” functionality in Visual Studio. The second was to use the command line tool SVCUTIL to generate a proxy class and configuration file that you then add to your project. The last technique is to hand roll your own proxy.

Don’t Panic!

It’s not as difficult as it sounds.

Let’s start with adding a new console application to our solution called WebBagles.Client.Custom. Your solution should look like this:

Add references to the .NET assembly System.ServiceModel and to the WebBagels project (the one with your service contract in it) Now add a new C# class called proxy.cs. Change the name of the class from proxy to BagelOrderServiceClient, and have it inherit from ClientBase<IBagelOrderService> and IBagelOrderService. Let Visual Studio/Resharper/elvin magic/whatever create the stub methods for your IBagelOrderService interface. When that’s all done,the contents of your proxy.cs file should look like this:

You don’t have to change the name of your cs file to proxy.cs. I did this to make it the same as the other projects. It’s just a cs file, you can name it whatever you want.

This should look pretty familiar. Much like our service implementation we’ve simply implemented the service contract interface. we’ll use a method from the ClientBase base class to do our heavy lifting:

Our base class has a property called Channel, which provides us direct access to the communications channel between the client and the service. A channel is made up of things like encoders, security protocols, wire transfer protocols, etc. Right now all you need to worry about is that calling the corresponding method on the Channel will invoke the communications stack and call the method on the service.

Our client code should look familiar if you read the last post…

So now we have a proxy and the client code to invoke it. It complies, so CLEARLY we are done! Ship it!

Well… let’s just try to run it once to be sure…

Oh yeah, the configuration file. Guess we need to deal with that.

Configuration the Easy(er) Way

For the most part we’ve had the files provided for us; Add Service Reference and SVCUTIL both created our app.config files and as you’ll recall and we *ahem* borrowed the config for our service.

With this approach we’re not so lucky; we’ll need to do it ourselves.Go ahead and add an app.config file to the WebBagles.Client.Custom project.

The good news here is that we don’t have to write all that ugly XML by hand. Instead we’ll be employing the WCF configuration editor. Right click on the app config file in the WebBages.Client.Custom project and select Edit WCF Configuration:

This will open the WCF configuration editor with the app.config file already loaded:

From this tool you can pretty much do any WCF configuration task you may need. We’ll use this to create our client endpoint.

In the configuration tree view on the left click on the Client node:

You may or may not have an SB endpoint already listed here. The SB endpoint seems to be some sort of remnant for a .NET-based SDK. It doesn’t do anything and wont cause any problems, so just ignore it.

Besides, we’re here to create our own endpoint. So lets do just that. Click on the “Create a New Client…” link to open the “New Client Element Wizard:

And here we make a choice. If you have the app.config file from the service you are consuming you can just point this tool at it and it will figure out everything for you. It’s like magic. And, if you have that configuration file, it’s the best way to go. But it would also make for a pretty short demo, so we’re gonna pretend that we don’t have that file and select “Manually” to create our own endpoint from scratch. Select the Manually radio button and click Next:

We’ll need to specify the contract of the service we want to consume. This, for review, tells us what methods are available on the service and how they are called. Hit the Browse button and you’ll see something similar to the standard file open dialog:

In this case we are going to be looking for the assembly with our service contract in it. In this case it will be in the bin/Deabug folder:

Double click on the WebBagels.dll and you’ll see something a little different:

We’re actually looking for a service contract; not an assembly. Double clicking on the assembly with our contract in it caused the wizard to open the assembly and find all service contracts in it. In our case we only have the one. Select it and click the Open button.

Now that we have our contract selected, it’s time to move on to the next step. Click the Next button.

We need to select our binding, and we’ll do it here. We have the full variety of bindings that ship with WCF available to us here. We’ve been using HTTP all this time, and right now we only have an HTTP endpoint on our service, so we’ll stick with that. Select HTTP (if it’s not already selected) and click Next

There are several types of HTTP bindings available. Selecting Basic Web Services Interoperability translates to the basicHttpBinding, which is sort of the “legacy” binding. It’s primarily for service that are VERY old and don’t support the WS-* standards or pre-date the WS-I 1.1 Basic Profile. We’ll stick with Advanced Web Services interoperability. Select that, make sure Simplex communication is selected and click the Next button.

Finally we get around to providing the address for our service! If you forgot this you can copy it from the host applications app.config file. Simply paste it in and click Next

There are situations were you will need to specify multiple endpoints for your client. In this case you’ll need to name your endpoints and when you new-up your proxy provide it with the name of the endpoint you want it to use. We only have the one endpoint, so leave the Name field as is and click the Next button:

Here is the summary of choices we’ve made. Note the binding. All along we’ve been using the wsHttpBinding. But the configuration editor has selected the ws2007HttpBinding for us. The ws2007HttpBinding is an implementation of the Organization for the Advancement of Structured Information Standards (OASIS) standards for http bindings. This mainly focuses around the implementation of reliable services. For now you just need to be aware that is it NOT compatible with the wsHttpBinding used by our service host. We need to change it.

Click the Finish button and you’ll see that our new endpoint as been added to the client configuration:

Click on the endpoints name (in this case it’s empty) and it will show you the endpoint details. You’ll see that true to it’s word the configuration tool as set our binding to the ws2007HttpBinding:

Changing this is easy. Just click on the drop down arrow next to the binding name and you’ll see a list of available bindings. Select wsHttpBinding. Your endpoint should look like this:

Select File | Save from the menu. DON’T forget this step or you’ll have to do this process all over again. Close the configuration tool and go back to Visual Studio. Visual Studio will alert you that one of your open files has changed, tell it that everything is OK by clicking Yes.Your clients app.config file should look similar to this:

All that’s left is to test it. Start the host application and when it’s ready to start accepting requests start the WebBagles.Client.Custom application. It should call the service and display the result as you can see here:

In answer to the question you’re asking yourself now, yes: you can use this WCF configuration manager to create host-side service information to, and we’ll do this in a future post.

These last two posts covered a lot of content Congrats if you made it all the way through both of them! Next time we start look at WCF contracts.

Code on!