The client will validate that the connection string and entity names are well-formed, but there is no dedicated operation for testing its ability to communicate with Service Bus.
Connections and links are established lazily when the first network operation that requires them is invoked. There are two approaches that occur to me which would trigger network resource creation without being intrusive.
Create a message batch
In order to ensure that the batch size does not exceed the limits for a given resource, the ServiceBusSender
must query the queue/topic. In the case where the client is misconfigured, it will throw.
// In a real scenario, you would want to create these as
// singletons and reuse them for the lifetime of the application.
await using var client = new ServiceBusClient("<< Connection String>>");
await using var sender = client.CreateSender("<< Queue/Topic >>");
var valid = true;
try
{
using var batch = await sender.CreateMessageBatchAsync().ConfigureAwait(false);
}
catch (Exception ex)
when (ex is ServiceBusException
|| ex is IOException
|| ex is SocketException)
{
valid = false;
}
Peek a message
Peeking a message will not cause the message to be locked or otherwise impact receiving it.
await using var client = new ServiceBusClient("<< Connection String>>");
await using var receiver = client.CreateReceiver("<< Queue/Subscription >>");
var valid = true;
try
{
_ = await receiver.PeekMessageAsync().ConfigureAwait(false);
}
catch (Exception ex)
when (ex is ServiceBusException
|| ex is IOException
|| ex is SocketException)
{
valid = false;
}
Interactions with each queue, topic, and subscription make use of a dedicated AMQP link, so each would need to be tested individually if you'd like to ensure that the name matches a known Service Bus entity.