0

I'm following this answer from a different question, trying to get my WCF service to only handle GET requests. I've added the [WebGet] to my operation, added an endpoint behavior with the <webHttp />, changed my default endpoint to use said behavior, and changed the default endpoint's binding to webHttpBinding.

web.config's system.servicemodel looks like:

<system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="">
            <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
            <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>
      <endpointBehaviors>
        <behavior name="webBehavior">
          <webHttp />
        </behavior>
      </endpointBehaviors>
  </behaviors>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
    multipleSiteBindingsEnabled="true" />

  <services>
    <service name="TestServiceLibrary.TestService">
      <endpoint behaviorConfiguration="webBehavior"
         address=""
         binding="webHttpBinding"
         contract="TestServiceLibrary.ITestService" />
      <endpoint 
         address="mex" 
         binding="mexHttpBinding" 
         contract="IMetadataExchange" />
    </service>
  </services>
</system.serviceModel>

This makes my service callable like: TestService.svc/GetData?value=x and that works great. Now I want to add a Service Reference to a client project. When I do that, the client project's app.config file does not get the binding and client endpoint configured. If I remove my behavior webBehavior above, change the default endpoint binding back to wsHttpBinding, and re-add the client's service reference - the client binding and endpoint are added successfully but I've lost GET support.

I realize I could leave the default endpoint using wsHttpBinding and add an endpoint with a different address set to binding webHttpBinding and a behavior with <webHttp />, but I would really like the client app to be using GET.

EDIT:

I'm also interested in why the config fails to update in this situation. I'm wanting to allow consumption of this service to be low-friction (add the service reference through visual studio and then start making calls), so manually setting up the client config file is not ideal.

Community
  • 1
  • 1
Ethan
  • 628
  • 2
  • 6
  • 20

1 Answers1

0

Try this configuration below. I have not tested it but it should work fine. Also, I would suggest to make the client yourself using this example. Note that ISampleService interface (in your case TestServiceLibrary.ITestService) and all datacontracts that are referenced by this interface should be in separate assembly which is referenced as dll by service and client.

<system.serviceModel>
    <client>
        <endpoint behaviorConfiguration="webBehavior" address="url_to_TestService.svc" binding="webHttpBinding" contract="TestServiceLibrary.ITestService" />
    </client>
    <behaviors>
        <endpointBehaviors>
            <behavior name="webBehavior">
                <webHttp />
            </behavior>
        </endpointBehaviors>
    </behaviors>
</system.serviceModel>
pepo
  • 8,644
  • 2
  • 27
  • 42
  • Thanks for the answer. I know this is going to sound picky, but I'm really wanting it to be a low-friction ordeal to consume this service, and having to manually set-up the config file is going to be too much to ask of some of the parties that want to use this. I guess I should revise my question to include that I'm also interested in a reason as to why adding a service reference through Visual Studio doesn't include the config in this situation. – Ethan Apr 04 '14 at 13:19
  • If you implement wcf client yourself (like I suggested) you could also set all these settings in code. – pepo Apr 04 '14 at 13:29
  • sorry, but I am really trying to avoid any manual repeated client configurations like that - even if it is in code. I'm having a hard time moving on this point since Visual Studio handles the configuration so gracefully in one case and then not at all in another. – Ethan Apr 04 '14 at 13:54