c# – WCF Discovery返回硬编码的URL

前端之家收集整理的这篇文章主要介绍了c# – WCF Discovery返回硬编码的URL前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
宏伟的设计如下:

>某些应用程序被安装为Windows服务
>网络上可能有几个
他们每个人都暴露了一些网络接口(把它视为“远程控制”或“配置” – 那种事情)
>然后有另一个应用程序作为该接口的客户端(使用相同的类比 – “遥控器”或“配置工具”)
>后者的目标是在网络上嗅出前者的所有实例,将其作为列表显示用户,并允许用户使用该暴露的界面(即“远程控制”或“配置” “他们)
>为了简单起见,我们假设每个人都在同一个网络中 – 也就是说,每个人都可以听到对方的UDP广播.

很简单,呃我过去常常在十几岁的时间里用自己的基于UDP广播的发现机制来建立这样的事情.

但是现在我以为我会很酷和臀部,并且在Ad Hoc模式下随着WCF Discovery而出现.它的工作原理谁能告诉:-)

但不完全
如我在herethere之前所指出的,发现返回了服务配置中的硬编码URL.也就是说,如果服务具有< baseAddresses>< add baseAddress =“net.tcp:// localhost:1234 / My / Service”/>< / baseAddresses>在它的配置文件中,那正是我要从发现客户端获得的 – 包括“localhost”部分.

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

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

为了节省大家的时间,一些不起作用的想法:

>在部署时更改服务的配置文件,编码它的真实IP地址或机器名称.
不起作用,因为IP和机器名称可能会改变.
>从代码(至少部分地)配置服务,使用当前的IP或机器名来构造URL.
不行机器名称是无用的,因为网络中可能没有一个dns. IP是无用的,因为计算机可能同时在几个网络上,因此有几个IP地址(这不是假设的,我们实际上有这样的情况).哪一个使用呢?

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

解决方法

您应该可以用通配符替换localhost来解决这个问题:
<baseAddresses><add baseAddress="net.tcp://*:1234/My/Service" /></baseAddresses>
原文链接:https://www.f2er.com/csharp/96212.html

猜你在找的C#相关文章