什么导致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

回答

相关问题