Integrate with Azure Service Bus Messaging

This skill equips Claude with Azure.Messaging.ServiceBus (v7.20.1) for enterprise messaging on .NET: sending and receiving messages on queues and topic subscriptions, background processing with ServiceBusProcessor, ordered FIFO sessions, dead-letter handling, cross-entity transactions, and administration (ServiceBusAdministrationClient) for creating and configuring queues, topics, and subscriptions.

Use it when writing .NET code that needs reliable, ordered, or transactional message delivery - sending single messages or safe batches, completing/abandoning/deferring/dead-lettering a received message, running a long-lived background processor with automatic lock renewal, processing messages in strict per-session order, moving a message across two queues inside a TransactionScope, or reading directly from a queue's dead-letter subqueue (ServiceBusReceiverOptions { SubQueue = SubQueue.DeadLetter }) to inspect why messages failed. Its own best-practice guidance treats clients/senders/receivers/processors as thread-safe singletons that should be disposed in order (senders/receivers/processors before the client), prefers DefaultAzureCredential over connection strings in production, and recommends AmqpWebSockets transport when ports 5671/5672 are blocked. For simple pub/sub event routing or high-throughput event streaming rather than enterprise queueing, the related Azure.Messaging.EventGrid or Azure.Messaging.EventHubs SDKs are the better fit.

Inputs: a ServiceBusClient built from a fully-qualified namespace plus DefaultAzureCredential (recommended) or a connection string, then a sender/receiver/processor created against a queue or topic+subscription name; ServiceBusMessage bodies, optional SessionId, and settlement calls (CompleteMessageAsync, AbandonMessageAsync, DeferMessageAsync, DeadLetterMessageAsync with a reason and description). Outputs: ServiceBusReceivedMessage objects with Body, dead-letter metadata (DeadLetterReason, DeadLetterErrorDescription), and session state via GetSessionStateAsync/SetSessionStateAsync (with RenewSessionLockAsync to extend a held session lock). A ServiceBusProcessor wires ProcessMessageAsync and ProcessErrorAsync event handlers instead of a manual receive loop, and options like AutoCompleteMessages and MaxConcurrentCalls control its behavior; the error handler receives the exception, its ErrorSource, and the affected EntityPath.

Built on Azure.Identity for authentication, with first-class ASP.NET Core dependency injection (AddAzureClients + AddServiceBusClientWithNamespace). Admin operations (CreateQueueAsync, CreateTopicAsync, CreateSubscriptionAsync) configure MaxDeliveryCount, LockDuration (default 30s), RequiresSession, and dead-lettering on message expiration. Errors surface as ServiceBusException with a Reason (e.g. ServiceBusy, which should prompt a retry with backoff rather than an immediate failure).

dotnet add package Azure.Messaging.ServiceBus
dotnet add package Azure.Identity

.NET developers building enterprise messaging between services - order processing pipelines needing FIFO guarantees, systems requiring dead-letter visibility into failed messages, or anything needing transactional send/receive across queues - and who follow the skill's remaining guidance to prefer safe batching (CreateMessageBatchAsync + TryAddMessage) over unbounded sends and to catch ServiceBusException by Reason for transient-error retries.