views:

511

answers:

2

I have two websites on the same machine. The first (client) references a WCF service on the second site(server).

How do I set the address for the service reference? When moving from development on my local machine to the group development server, how do I change the url for the service? The sites are differentiated by host headers, like http://dev.admin/... and http://dev.public/...

I sense that this can be handled using multiple endpoints, but I'm very new to WCF and really don't have a clue what I'm doing here.

A: 

Easiest way: run the WCF parts on different ports.

Steven Sudit
Care to elaborate? I'm not sure what you mean by "WCF parts". Also, is it possible to specify a port for the wcf that's different than the site to which it belongs? Why would I want to do that?
David Lively
Sorry, I'm more used to hosting WCF in services, not inside IIS. For your circumstances, you might want to look at http://ferventcoder.com/archive/2007/10/02/WCF-in-IIS-with-Websites-that-have-Multiple-Identities.aspx
Steven Sudit
+1  A: 

After much frustration, I managed to determine that both web.config files (on the client and server, both of which are web apps in this case), the following sections have to be changed:

Client:

   <client>
      <endpoint 
        address="http://mysite.com:port/services/someservice.svc"
        binding="basicHttpBinding" 
        bindingConfiguration="BasicHttpBinding_ISomeService"
        contract="MyServices.ISomeService" 
        name="BasicHttpBinding_ISomeService" />

    </client>
  </system.serviceModel>

Server

 <system.serviceModel>
    <serviceHostingEnvironment>
      <baseAddressPrefixFilters>
        <add prefix="http://mysite.com:port/services"/&gt;
      </baseAddressPrefixFilters>
    </serviceHostingEnvironment>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MyServices.SomeServiceBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <services>
      <service behaviorConfiguration="MyServices.SomeServiceBehavior"
        name="MyServices.SomeService">
          <endpoint address="http://mysite.com:port/services/someservice.svc" 
                    name="endpoint.SomeService"
                    binding="basicHttpBinding" 
                    bindingConfiguration="" 
                    contract="MyServices.ISomeService"/>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>
  </system.serviceModel>

The thing to note here is that the host address in all three relevant sections (client endpoint address, server baseAddressPrefixFilter value, and server endpoint address) have to match.

I'm able to switch between servers by modifying these, as long as they match. I would still prefer a way to set this based on which machine the server is running on, but this works for the moment.

WCF Impressions What's hot: persistent object. The client proxy object (created when you add a service reference) maintains a persistent connection to the service on the server. The service instance referenced by the client proxy maintains its state between calls, which can simplify method signatures and makes the client proxy object, and the service as a whole, much more useful for certain applications. Parameter object types can be shared between the client and server if they're declared in a common library, meaning that you don't have to create two very similar classes or wrapper classes to pass non-primitive data structures back and forth.

What's not: configuration is a royal pain, poorly documented, and far too involved. Getting this to work in a test/dev/staging/production environment configuration where the service neesd to be aware of its location is frustrating. I'm not convinced that making the service aware of its domain url (rather than, say, a relative path to whatever it's running on) has any significant benefit, security concerns aside.

That said, I'm continuing to go down the WCF path as the advantages thus-far outweigh the headaches.

David Lively