Question

The grand design is the following:

1. There is certain application that gets installed as a Windows Service
2. There may be several of these on the network
3. Each of them exposes some interface to the network (think of it as “remote control” or “configuration” – that kind of thing)
4. Then there is another application that acts as a client for that interface (using same analogies – “remote controller” or “configuration tool”)
5. The objective of the latter is to sniff out all instances of the former on the network, display them as a list to the user and allow the user to poke them in different places using that exposed interface (i.e. “remote control” or “configure” them)
6. For the sake of simplicity, let’s assume that everybody is in the same network – that is, everybody can hear each other’s UDP broadcasts.

Pretty straightforward, eh? I used to build this kind of things by the dozen in ye olden days, using roll-my-own UDP-broadcast-based discovery mechanism.

But now I thought I’d be cool and hip, and go with the groovy WCF Discovery in Ad Hoc mode. And it works! Who could tell? 🙂

But not quite.
As was noted before me here and there, the discovery returns the hard-coded URL from service’s config. That is, if the service has <baseAddresses><add baseAddress="net.tcp://localhost:1234/My/Service" /></baseAddresses> in it’s config file, then that’s exactly what I’m going to get from discovery client – including the “localhost” part.

Needless to say, if I try to call the service using that URL, the result is not thrilling.

So the question is: how do I make the discovery client give me the usable URL instead of that localhost-ish garbage?

To save everybody’s time, a couple of thoughts that don’t work:

1. Change the service’s config file at deployment time, encoding it’s real IP address or machine name.
   Doesn’t work, because both IP and machine name may change.
2. Configure the service from code (at least partially), using current IP or machine name to construct the URL.
   Doesn’t work. Machine name is useless, because there might not be a dns in the network. IP is useless, because the computer may be on several networks at once, and thus, have several IP addresses (this is not hypothetical, we actually do have this situation). Which one to use then?

In other words, I need not to tweak the service, but rather to make the discovery client give me the address that the discovery response came from.

Answer 1

You should be able to fix this by replacing localhost with a wildcard:

<baseAddresses><add baseAddress="net.tcp://*:1234/My/Service" /></baseAddresses>