[Discussion] Service Bus - Track 2 - Connection Strings

The intent of this issue is to solicit feedback from the community in advance of the GA of the next major version of the Service Bus library (which will follow several Preview releases). As a reference, the .NET Azure SDK guidelines can be found here: https://azure.github.io/azure-sdk/dotnet_introduction.html Terminology: Track 0 refers to the WindowsAzure.ServiceBus library Track 1 refers to the Microsoft.Azure.ServiceBus library Track 2 refers to the new library, Azure.Messaging.ServiceBus, we are working on releasing.

In the previous version of the library, the connection string could be used to specify things like OperationTimeout and Transport type. The way that these options are added to the string is through the use of the ServiceBusConnectionStringBuilder .

Our philosophy for connection strings for the Track 2 libraries can be found here:

Client libraries may support providing credential data via a connection string ONLY IF the service provides a connection string to users via the portal or other tooling. Connection strings are generally good for getting started as they are easily integrated into an application by copy/paste from the portal. However, connection strings are considered a lesser form of authentication because the credentials cannot be rotated within a running process.

DO NOT support constructing a service client with a connection string unless such connection string is available within tooling (for copy/paste operations

In our new library, the TransportType and OperationTimeout can be specified within the options that are passed when creating a new client instance. As such, we are proposing that support for including the TransportType and OperationTimeout within the connection string should not be included. This would also mean that there is no need to expose the ServiceBusConnectionStringBuilder.

var client = new ServiceBusClient(connectionString, new ServiceBusClientOptions
{
    TransportType = ServiceBusTransportType.AmqpWebSockets,
    RetryOptions = new ServiceBusRetryOptions
    {
        TryTimeout = TimeSpan.FromSeconds(30)
    }
});

[SeanFeldman]

It reminds me of a joke.

- Dad, dad, why the sun rises in the east and sets down in the west? - Son, does it work? - Yes, dad. - Then don’t touch it.

In the previous version of the library, the connection string could be used to specify things like OperationTimeout and Transport type.

I’m somewhat confused by this question. Are you saying that because the portal does not generate a connection string with TransportType and OperationTimeout arguments by default, those should not be accepted/exposed via the ServiceBusConnectionStringBuilder?

If so, then it’s a false direction. Authentication is not generated in the portal. Does that mean it should not be supported either?

[JoshLove-msft]

Thanks for all of the discussion, closing as there is no further action item here.