Integrate with Azure Service Bus Messaging

This skill covers Azure.Messaging.ServiceBus (.NET, v7.20.1 stable), an enterprise messaging SDK for queues, topics, subscriptions, and sessions. ServiceBusClient is the entry point, creating a ServiceBusSender for sending, a ServiceBusReceiver for pulling messages from a queue or topic subscription, a ServiceBusSessionReceiver via AcceptNextSessionAsync/AcceptSessionAsync for ordered per-session processing, and a ServiceBusProcessor/ServiceBusSessionProcessor for event-driven background processing with automatic lock renewal. A separate ServiceBusAdministrationClient handles CRUD on queues, topics, and subscriptions - creating a queue with options like MaxDeliveryCount, LockDuration, RequiresSession, and DeadLetteringOnMessageExpiration, then updating existing properties (e.g. a longer LockDuration) or deleting entities entirely once they're no longer needed.

Use it when a .NET application needs reliable, ordered, or transactional message delivery - point-to-point queues, pub/sub via topics and subscriptions, FIFO ordering within a session, or dead-lettering malformed messages for later inspection. Cross-entity transactions (enabled via EnableCrossEntityTransactions) let a receive-and-forward pattern span two queues atomically inside a TransactionScope. If ports 5671/5672 are blocked, the SDK falls back to AmqpWebSockets transport rather than failing outright.

Sending uses safe batching to avoid oversized-message errors:

using ServiceBusMessageBatch batch = await sender.CreateMessageBatchAsync();
if (batch.TryAddMessage(new ServiceBusMessage("Message 1")))
{
    // Message added successfully
}
await sender.SendMessagesAsync(batch);

Receiving returns a ServiceBusReceivedMessage whose body is read via .Body.ToString(); each message must then be settled with one of four outcomes - CompleteMessageAsync (removes it), AbandonMessageAsync (releases the lock for redelivery), DeferMessageAsync (requires a separate ReceiveDeferredMessageAsync to retrieve later), or DeadLetterMessageAsync with a reason and description (moves it to the dead-letter subqueue, readable via a receiver configured with SubQueue.DeadLetter and the message's DeadLetterReason/DeadLetterErrorDescription). Session messages carry a SessionId, and a session receiver can get/set session state as BinaryData and renew its own lock. Errors surface as ServiceBusException with a Reason such as ServiceBusFailureReason.ServiceBusy, distinguishing transient conditions worth retrying from permanent failures. Topics work the same way as queues from the caller's side - a sender targets the topic name, and a receiver is created against a specific topic/subscription pair rather than a queue name.

Authenticates via Azure Identity's DefaultAzureCredential (recommended) or a connection string, wires into ASP.NET Core via AddAzureClients/AddServiceBusClientWithNamespace, and is distributed as the NuGet package Azure.Messaging.ServiceBus, alongside sibling messaging SDKs Azure.Messaging.EventHubs and Azure.Messaging.EventGrid.

.NET developers building reliable messaging - queues, pub/sub topics, ordered sessions, or transactional cross-queue workflows - who follow the SDK's own guidance: treat clients/senders/receivers/processors as thread-safe singletons, always dispose them (senders/receivers/processors before the client), prefer DefaultAzureCredential over connection strings in production, use processors rather than manual polling for background work, batch sends safely with CreateMessageBatchAsync/TryAddMessage, and use sessions whenever strict per-key ordering matters.