Azure Service Bus transport
Configure the Azure Service Bus preview transport.
This guide covers namespace provisioning, C# and Java configuration, topology ownership, verified interoperability, and the limitations that remain before a stable transport release.
Routine emulator tests verify directed sends and publications in every direction between MassTransit 8.5.1 and the C# and Java clients. Periodic live-Azure tests cover the management and broker behavior the emulator cannot reproduce. The project is still pre-1.0, so preview releases may make breaking configuration changes.
1. Provision a namespace
Install the Azure CLI, sign in, and create an isolated Service Bus namespace. Replace the namespace placeholder with a globally unique name. Use Standard or Premium: the Basic tier does not support the topics and subscriptions required for publish/subscribe.
The default Create topology mode uses the administration API, so this first setup grants the connection Manage, Send, and Listen. MyServiceBus then provisions entities when the bus starts.
2. Read the connection string safely
Load the namespace connection string into your deployment’s secret store or an environment variable. Do not commit it to source control or put it in a client-side configuration file.
The current transport configuration accepts an Azure Service Bus SAS connection string. Managed identity and TokenCredential-based configuration are not exposed yet.
3. Install the transport
The transport package brings in the corresponding MyServiceBus runtime and Azure SDK dependencies.
4. Configure the bus
Register consumers through the same factory shape used by the RabbitMQ transport. In the default mode, ConfigureEndpoints creates each consumer endpoint and its publish subscription.
Topology created at startup
For a consumer endpoint named orders, MyServiceBus creates a queue, a topic for each consumed message contract, and a subscription that forwards messages into the queue. Failure companions follow the same conventions used for MassTransit interoperability.
Primary peek-lock delivery queue
Original messages after terminal failure
Published Fault<T> details
Messages with no recognized consumer
Infrastructure-managed topology
If Terraform, Bicep, or another deployment system owns the entities, switch both clients to PreProvisioned. The application will use the configured queues, topics, subscriptions, and failure companions without trying to create them. Give that runtime connection only the Send and Listen rights it needs.
Request clients normally create unique auto-delete response queues. A pre-provisioned environment must also map temporary response endpoint names to infrastructure-owned queues.
MassTransit interoperability
Azure entity names are part of the wire contract. Automatic consumer endpoint names follow MassTransit’s default suffix rules in both clients, and corresponding message contracts resolve to the same topic names. Use matching explicit entity-name overrides in MyServiceBus and MassTransit when defaults are not suitable. Emulator tests cover bidirectional directed sends and publication for C# and Java. Live tests cover cloud topology, subscriptions, companions, correlated responses and faults, lock renewal, native temporary queues, and terminal failure preservation in _error.
Use the emulator for ordinary transport changes. Run an isolated live namespace for releases, relevant SDK or topology changes, authentication work, or a suspected emulator discrepancy, then delete it immediately to limit cost.
Remove an evaluation environment
If the resource group is dedicated to this evaluation, delete it when you finish to stop further Azure charges. This removes the namespace and every entity inside it.
Azure CLI command details and Service Bus tier behavior are documented by Microsoft Learn.