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。