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

c# wcf service-discovery wcf-discovery
Edit
Report