- Part 1: Creating the minimal bare service
- Part 2: Extract a service contract interface
- Part 3: Creating client configuration
- Part 4: Separating out the client and interface
Now that we have a real interface for the service contract, we can use ChannelFactory to talk to it! So what happens if we try to use it right now? Well, we haven’t made any configuration for the client, so understandably we get an exception:
Now, in this case we happen to be in the code that has access to the service host, and as such we can just pass in the endpoint to the channel factory since it can figure out everything from that:
That works, but obviously it’s “cheating” since normally clients won’t have access to the service host, so we should do the actual client configuration instead 🙂
This is one of the real strengths of the Service Config Editor – if you point it at a service config, it can generate the client config for you. (Sweet!)
Normally the client would be in a separate project, but we’ll do it in the same project for now to keep it simpler for now (we’ll separate it out later)
After browsing to and selecting the app.config for our service:
(it’s the only entry in the drop-down since we only have one service endpoint)
You can choose a different name, but I stick with the default here.
NOTE: while it says ‘(Default)’ it actually means the default, which is an empty string. This could be understandably confusing. 🙂
We can check what’s added in the app.config:
<client> <endpoint address="http://localhost/testing" binding="" bindingConfiguration="" contract="SimpleWcfRestServiceConsoleApp.MyService" name="" kind="webHttpEndpoint" endpointConfiguration=""> <identity> <certificateReference storeName="My" storeLocation="LocalMachine" x509FindType="FindBySubjectDistinguishedName" /> </identity> </endpoint> </client>
Notice that we’re also using the standard webHttp endpoint (the ‘kind’ attribute, just like in our service config).
I’m not a fan of the empty attributes included nor the identity cert stuff, and since I don’t plan on using those, while I could change the identity stuff in the service config editor, I’ll just edit the XML to clean it up:
<client> <endpoint address="http://localhost/testing" contract="SimpleWcfRestServiceConsoleApp.MyService" kind="webHttpEndpoint" /> </client>
Now the WCF REST client calls (using ChannelFactory!) will work.
NOTE: we’re passing an endpoint configuration name, it just happens to be an empty string since we didn’t specify a non-default name. That is NOT the same thing as not specifying a configuration name at all, since doing so will (still) result in an exception since there’s no configuration specified:
If we don’t like that (default) endpoint config name (empty string) we can just change it to add a specific name, of course:
<client> <endpoint name="ourWcfRestClientEndpoint" address="http://localhost/testing" contract="SimpleWcfRestServiceConsoleApp.MyService" kind="webHttpEndpoint" /> </client>
Now we can use that name in our ctor call: