c# - WCF发现返回硬编码的URL

宏伟的设计如下:

某些应用程序已作为Windows服务安装

网络上可能有几个

他们每个人都向网络公开一些接口(interface)(将其视为“远程控制”或“配置”-诸如此类)

然后还有另一个应用程序充当该接口(interface)的客户端(使用相同的类比-“远程 Controller ”或“配置工具”)

后者的目的是嗅探网络上前者的所有实例，将其作为列表显示给用户，并允许用户使用该公开的界面在不同的地方戳它们(即“远程控制”或“配置”)。 “他们)

为了简单起见，我们假设每个人都在同一个网络中-也就是说，每个人都可以听到彼此的UDP广播。

很简单，是吗？在过去，我曾经使用基于滚动的我自己的基于UDP广播的发现机制来构建这种东西。

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

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

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

所以问题是:如何使发现客户端为我提供可用的URL，而不是该本地主机的垃圾？

为了节省大家的时间，有两种想法行不通:

在部署时更改服务的配置文件，将其编码为真实IP地址或计算机名称。
不起作用，因为IP和计算机名称都可能更改。

使用当前IP或计算机名称从URL(至少部分)配置服务，以构造URL。
不起作用机器名称没有用，因为网络中可能没有dns。 IP没有用，因为计算机可能一次位于多个网络上，因此具有多个IP地址(这不是假设的，我们实际上做遇到这种情况)。那要用哪一个呢？

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

最佳答案

您应该可以通过使用通配符替换localhost来解决此问题:

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

关于c# - WCF发现返回硬编码的URL，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4728818/