2

当我们尝试使用 Azure 服务总线中继地址和 webHttpRelayBinding 启动 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 服务总线 nuget 包。然后，您需要使用 Azure 凭据更新 App.config 中名为 Microsoft.ServiceBus.ConnectionString 的 appSettings 下的 ConnectionString。

我们已经使用 TCPViewer 查看正在使用的端口并且没有发现冲突。在我们的实际项目中，我们尝试了 webHttpRelayBinding 和 netTcpRelayBinding。最后，我们想使用 netTcpRelayBinding，这样我们就可以使用 DuplexChannels。

关于导致我们问题的任何想法？我们是否缺少一些未记录的配置步骤？每个教程都让这看起来很简单，但我们发现每个教程都缺少一些关键步骤。因此，如果我们错过了更多步骤，我不会感到惊讶。

4

2 回答 2

3

对于使用 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-26T21:21:02.577 回答
2

事实证明这里的解决方案很简单。如果你使用 NamespaceManager 创建一个中继，你会得到一个 AddressAlreadyInUseException。我想这就是为什么 NamespaceManager 没有在任何与继电器相关的地方记录的原因。

只要您的命名空间是在云中创建的并且您的凭据设置正确，该示例就可以很好地工作。就我而言，我需要使用 SharedAccessSignature 而不是 SharedSecret。我在过去 3 天中找到的所有样本都使用 SharedSecret 直到上周五。

托管 WCF 服务时，它会自动在命名空间中创建中继路径。如果由于它已经存在而无法创建它，则会收到 AddressAlreadyInUseException。只要您的信誉良好，那么一切都很愉快。

于 2014-10-21T19:58:22.727 回答