ServiceBusTransportType is always AmqpTcp

[kepar]

Describe the bug
When creating a new ServiceBusClient the ServiceBusTransportType configured via options or the connectionstring is ignored.
the resulting TransportType is always AmqpTcp.

Expected behavior
ServiceBusTransportType.AmqpWebSockets should be used

Actual behavior (include Exception or Stack Trace)
Wrong Transporttype is used, and gets blocked by corporate firewall.

To Reproduce

1. new console application

2. Add PackageReference to "zure.Messaging.ServiceBus Version 7.1.2

    var client = new ServiceBusClient(connectionString, new ServiceBusClientOptions { TransportType = ServiceBusTransportType.AmqpWebSockets });
              
    if (client.TransportType != ServiceBusTransportType.AmqpWebSockets)
    {
        throw new NotImplementedException();
    }

or

    var client = new ServiceBusClient(connectionString + ";TransportType=AmqpWebSockets");

    if (client.TransportType != ServiceBusTransportType.AmqpWebSockets)
    {
        throw new NotImplementedException();
    }

Environment:

• Name and version of the Library package used: Azure.Messaging.ServiceBus 7.1.2
• Hosting platform or OS and .NET runtime version: Windows 10 .net Core 3.1
• IDE and version : Visual Studio 16.9.4

[jsquire]

Hi @kepar. Thank you for reaching out and we regret that you're experiencing difficulties. We definitely have a bug where the transport type isn't being reflected correctly in the ServiceBusClient property; the constructors aren't extracting it from the options. (example)

However, I did confirm that the transport is being respected and passed as part of the options to the transport level. WebSockets is used for establishing the connection with the Event Hubs service. Which leaves us still needing to figure out why you're seeing the traffic as blocked. Is there an error being returned by the client that you're able to share? Can you confirm that your firewall isn't blocking the wss protocol in a URL and that port 443 traffic is allowed?

---

LinqPad trace for TransportType through the stack:

var client = new ServiceBusClient("Endpoint=blah.foo.com;SharedAccessKeyName=blah;SharedAccessKey=fake", new ServiceBusClientOptions 
{
    TransportType = ServiceBusTransportType.AmqpWebSockets
});

client.TransportType.Dump();

var connection = typeof(ServiceBusClient).GetProperty("Connection", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(client);
connection.Dump();

var inner = connection.GetType().GetField("_innerClient", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(connection);
inner.Dump();

var scope = inner.GetType().GetProperty("ConnectionScope", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(inner);
scope.Dump();

var scopeTransport = scope.GetType().GetProperty("Transport", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(scope);
scopeTransport.Dump();

[kepar]

Hi @jsquire Thank u for the prompt reply!

I was indeed a bit to focused on the ServiceBusClient.TransportType property.
after some more tests I found that when using ";TransportType=AmqpWebSockets" in the connection string

var client = new ServiceBusClient(connectionString + ";TransportType=AmqpWebSockets");

the internal TransportType is not "correct" or maybe this is no longer supported:

with this exception as a result:

"A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond."

I can confirm it works as expected now when using the ServiceBusClientOptions (here I focused to much on the TransportType property without stepping further through my program)

so al that remains is the bug where the transport type isn't being reflected correctly in the ServiceBusClient property (when using the ServiceBusClientOptions)

[jsquire]

Hi @kepar. You are correct that the transport type must be set as an option; we don't support configuration of the clients via connection string - just the basic form needed to establish a connection and available in the Azure portal.

[jsquire]

I just fixed up the property mismatch and added some additional context around the connection string semantics. I'm going to close this out, but please feel free to reopen if you'd like to discuss further.