views:

72

answers:

2

Maybe I'm just not getting it, but I have a service that is deployed to an IIS 6 machine. That machine has a LAN address and a Public internet address.

How on earth am I supposed to be able publish this service with both accessible?

At first I thought: No big deal, 2 endpoints. So I have

<endpoint 
    address="Address 1" 
    binding="wsHttpBinding" 
    bindingConfiguration="DefaultBindingConfiguration" 
    name="RemoteEndpoint" />

<endpoint
    address="Address 2" 
    binding="wsHttpBinding" 
    bindingConfiguration="DefaultBindingConfiguration" 
    name="LocalEndpoint" />

The client code then looks like:

public void createServiceProxy()
{
    if (Util.IsOperatingLocally())
        this.proxy = new ProxyClient("LocalEndpoint");
    else
        this.proxy = new ProxyClient("RemoteEndpoint");
}

No dice. Can't add the service reference.

No protocol binding matches the given address 'Address 1'. Protocol bindings are configured at the Site level in IIS or WAS configuration.

Then I thought: Maybe the host tag and its dns tag will help. Nope, that's for authentication.

Then I thought: I'll use net.tcp for the local endpoint. Oops... IIS 6 doesn't support net.tcp.

Then I thought: I know, the ProxyClient constructor takes a remoteAddress string as its second parameter. Now it'll look like:

<endpoint
    address="" 
    binding="wsHttpBinding" 
    bindingConfiguration="DefaultBindingConfiguration" 
    name="MyEndpointName" />

public void createServiceProxy()
{
    if (Util.IsOperatingLocally())
        this.proxy = new ProxyClient("MyEndpointName", "Address 1");
    else
        this.proxy = new ProxyClient("MyEndpointName", "Address 2");
}

Apparently not. When trying to instantiate the ProxyClient...

Could not find endpoint element with name 'MyEndpointName' and contract MyService.IService' in the ServiceModel client configuration section.

Which leads me to the app.config whose generated client section looks like this:

<client>
    <endpoint address="http://localhost:3471/Service.svc" binding="customBinding"
        bindingConfiguration="MyEndpointName" contract="MyService.IService"
        name="MyEndpointName">
        <identity>
            <userPrincipalName value="DevMachine\UserNa,e" />
        </identity>
    </endpoint>
</client>

Which sure doesn't look right to me.

My next thought is not a healthy one. Please help.

+3  A: 

Here's what I do:

PortClient client = new PortClient(); // from the service reference

EndpointAddress endpointAddress;

if (local)
    endpointAddress = new EndpointAddress("http://local/Service.svc");
else
    endpointAddress = new EndpointAddress("http://remote/Service.svc");

client.ChannelFactory.CreateChannel(endpointAddress);
client.RemoteMethod();

etc.

Otávio Décio
If you're right, I'm naming my first born child Otávio.
SnOrfus
One day, I may just introduce you to little Otávio. Thanks.
SnOrfus
@SnOrfus - Glad for being of help and thank you for the honor :-)
Otávio Décio
A: 

Were you actually putting the strings "Address 1" and "Address 2" in the configuration file?

The framework always parses the address to know what transport to use. eg "http://myurl" will use http, "net.pipe://localhost/MyNamedPipeExample" will use IPC.

The error was caused because there was no prefix in the string "Address 1".

I believe this would have worked, without needing to hardcode the addresses:

<endpoint 
    address="http://serverName/ServiceName/Service.svc" 
    binding="wsHttpBinding" 
    bindingConfiguration="DefaultBindingConfiguration" 
    name="RemoteEndpoint" />

<endpoint
    address="http://www.companyName.com/ServiceName/Service.svc" 
    binding="wsHttpBinding" 
    bindingConfiguration="DefaultBindingConfiguration" 
    name="LocalEndpoint" />
Andrew Shepherd
No, I was calling them http://serverName/ServiceName/Service.svc (local) and http://ServiceName.CompanyName.com/Service.svc (remote) where there was forwarding setyo at the isp for the remote address to go to: http://ip.ServiceNam/Service.svc. The addresses were browsable.
SnOrfus
Sorry, just being absolutely sure (because the markup might have swallowed up some of your comment). Were you putting the "http://" prefix in the address names? If not, that would explain the error.
Andrew Shepherd