什麼導致Azure服務總線中繼WCF服務拋出AddressAlreadyInUseException

當我們嘗試使用Azure服務總線中繼地址和webHttpRelayBinding啓動我們的WCF服務時，我們得到一個AddressAlreadyInUseException。什麼導致Azure服務總線中繼WCF服務拋出AddressAlreadyInUseException

我們在這裏使用的例子：https://code.msdn.microsoft.com/Relayed-Messaging-Bindings-a6477ba0

的樣品不正確，除非你創建的接力與此代碼的工作：

string connectionString = ConfigurationManager.AppSettings["Microsoft.ServiceBus.ConnectionString"]; 
var namespaceManager = NamespaceManager.CreateFromConnectionString(connectionString); 

var tRelayExists = namespaceManager.RelayExistsAsync("Image"); 
if (!tRelayExists.Result) 
{ 
    var t = namespaceManager.CreateRelayAsync(new RelayDescription("Image", RelayType.Http)); 
    Task.WaitAll(t); 
    RelayDescription result = t.Result; 
}

做任何其他工作Program.Main前（）在你做這件事之前，你需要添加Azure Service Bus nuget包。然後，您需要使用Azure憑據更新名爲Microsoft.ServiceBus.ConnectionString的appSettings下的App.config中的ConnectionString。

我們使用TCPViewer來查看正在使用的端口並且沒有發現衝突。在我們的實際項目中，我們嘗試了webHttpRelayBinding和netTcpRelayBinding。在一天結束時，我們要使用netTcpRelayBinding，以便我們可以使用DuplexChannels。

關於是什麼導致我們的問題的任何想法？我們是否缺少一些無證的配置步驟？每個教程都使這看起來很簡單，但我們發現每個教程都缺少一些關鍵步驟。所以如果我們錯過了更多的步驟，我不會感到驚訝。

來源

2014-10-17 dannydwarren

原來這裏的解決方案很簡單。如果您使用NamespaceManager創建中繼，您將收到AddressAlreadyInUseException。我想這就是爲什麼NamespaceManager沒有記錄與繼電器有關的任何地方。

只要在雲中創建命名空間並且您的憑據設置正確，該示例就會很好地工作。在我的情況下，我需要使用SharedAccessSignature而不是SharedSecret。直到上週大約星期五，我在過去3天發現的所有樣本都使用了SharedSecret。

當WCF服務託管時，它自動在名稱空間中創建中繼路徑。如果它不能創建它，因爲它已經存在，你會得到AddressAlreadyInUseException。只要你的信譽好，那麼一切都很開心。

來源

2014-10-21 19:58:22 dannydwarren

對於使用NamespaceManager創建的服務總線實體，我發現需要將綁定IsDynamic屬性設置爲false。這會停止AddressAlreadyInUseException。

var binding = new NetTcpRelayBinding(); 
    binding.IsDynamic = false;

這是我找到了答案： http://www.codit.eu/blog/2014/12/securing-azure-service-bus-relay-endpoints-with-sharedaccesssignatures/

來源

2015-02-26 21:21:02

這是一個偉大的發現！這是在代碼中運行所有內容而不是由門戶配置的答案。 – dannydwarren 2015-03-10 05:01:23

什麼導致Azure服務總線中繼WCF服務拋出AddressAlreadyInUseException

回答

相關問題