WCF Discovery 返回硬编码 URL

Question

总体设计如下：

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

非常简单，是吗？在过去，我曾经使用自己的基于 UDP 广播的发现机制构建了十几个此类东西。

但现在我想我会很酷很时髦，并在 Ad Hoc 模式下使用时髦的 WCF Discovery。它有效！谁能告诉我呢？ :-)

但也不完全是。 正如我之前提到的here和there，发现返回来自服务配置的硬编码 URL。也就是说，如果服务的配置文件中有

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

，那么这正是我将从发现客户端获得的内容 - 包括“localhost”部分。

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

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

为了节省大家的时间，有几个行不通的想法：

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

这个，作为比较：自托管_和基本_地址

Answer 3

除通配符之外的另一个选项是使用计算机的 DNS 可解析主机名而不是 localhost。