WCF发现返回硬编码的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而不是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可解析主机名而不是localhost。