WCF发现返回硬编码的URL

Question

的宏伟构想是：

1. 有是被安装为Windows服务的某些应用程序
2. 可能有几个，这些网络
3. 每个上他们暴露了一些网络接口（将其视为“遥控器”或“配置” - 这种东西）
4. 然后有另一个应用程序充当该接口的客户端（使用相同的类比 - “远程控制器“或”配置工具“）
5. 后者的目的是在网络上嗅探出前者的所有实例，并将它们显示为列表给用户，并允许用户使用该公开的接口在不同的地方戳出它们。 “遥控”或“配置”）
6. 为简单起见，我们假设每个人都在同一个网络中 - 也就是说，每个人都可以听到对方的UDP广播。

很简单，呃？我曾经在过去的十几天里使用roll-my-own基于UDP广播的发现机制来构建这种类型的东西。

但是现在我想我会变得很酷并且很时髦，并且在Ad Hoc模式下使用groovy WCF Discovery。它的工作原理！谁可以告诉？ :-)

但并不完全。 正如前面提到的here和there所示，该发现从服务的配置中返回硬编码的URL。也就是说，如果该服务的配置文件中有<baseAddresses><add baseAddress="net.tcp://localhost:1234/My/Service" /></baseAddresses>，那么这就是我要从发现客户端获得的内容 - 包括“本地主机”部分。

不用说，如果我尝试使用该URL调用服务，结果并不令人兴奋。

所以问题是：我如何让发现客户端给我可用的URL而不是localhost-ish垃圾？

为了节省大家的时间，一对夫妇的想法，不工作：

1. 更改服务的配置文件在部署时，编码它是真实的IP地址或计算机名称。
   不起作用，因为IP和计算机名称可能会更改。
2. 使用当前IP或计算机名称来构建URL，从代码（至少部分）配置服务。
   不起作用。机器名称是无用的，因为网络中可能没有DNS。 IP是无用的，因为电脑可能一次在多个网络上，因此，有几个IP地址（这不是假设的，我们其实做有这种情况）。哪一个使用呢？

换句话说，我不需要调整服务，而是让发现客户端给我发现响应来自的地址。

Answer 1

你应该能够用通配符代替localhost解决这个问题：

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

Answer 2

请勿使用该配置。

以编程方式运行该服务。

这里的程式设计增加端点的一个例子：Programmatic_Endpoint_Configuration

而这一点，对于比较：Self-hosting_and_base_addresses

Answer 3

另一个通配符以外的选项是使用本机的DNS可解析主机名insthost。