Microsoft's SBMP cutoff stops WindowsAzure.ServiceBus apps that never set TransportType=Amqp

Triage starts with a text search. WindowsAzure.ServiceBus talks to Service Bus over SBMP by default, and any app whose connection string does not contain TransportType=Amqp is using it ^[5]. The project file tells you which package a service uses. The connection string tells you which protocol it speaks ^[5].

SBMP apps have a documented stopgap. Appending ;TransportType=Amqp to the connection string moves the same package onto AMQP 1.0 ^[6]. Microsoft Learn lists the side effects on the same page: OperationTimeout is ignored, Receive(TimeSpan.Zero) becomes a 10-second receive, and only the receiver that got a message can complete it by lock token ^[7]. Each of those hits a specific kind of code. On an empty queue, every zero-timeout call in a polling loop now waits 10 seconds. A design that receives on one instance and completes on another can no longer settle by lock token. Timeouts tuned through OperationTimeout stop applying.

According to the dev.to write-up, the flag also changes how message bodies are serialized ^[7]. If the producer and consumer of a queue ship separately, there will be a window where one end has switched and the other has not. I would test that mixed case before trusting the flag on either end. The write-up's own advice is to treat the flag as a way to buy a few weeks, not as the migration ^[8].

Microsoft.Azure.ServiceBus is the case you can schedule. Microsoft says the old libraries "can still be used beyond 30 September 2026", with no official support and no updates ^[3]. For this package that means no more fixes of any kind, security fixes included, and it has been officially deprecated for a while ^[16]. By the cutoff, its replacement will have been on offer for about 70 months ^[1].

In my view the replacement's core design is right. A single ServiceBusClient creates every sender, receiver and processor, and all of them share that client's one AMQP connection ^[12]. The write-up calls renaming types the easy half. In its sample, AutoComplete becomes AutoCompleteMessages and MaxAutoRenewDuration becomes MaxAutoLockRenewalDuration ^[15]. The harder half is changes that pass the build and show up later as duplicates, lost locks or messages nobody can read ^[14]. Settlement is first on that list. In the before-and-after handler, the old code completes through the queue client using message.SystemProperties.LockToken, and the new code calls args.CompleteMessageAsync(args.Message) on the processor's event arguments ^[13].

Relay users are exempt. According to the write-up, Microsoft staff wrote on Microsoft Q&A that WindowsAzure.ServiceBus is "NOT deprecated for usage with Relay" and will stay supported with WCF Relay until further notice ^[10]. The same thread points to Azure Relay Hybrid Connections as the long-term direction ^[10]. A project that uses the package for both relay and queues only has to move its queue and topic code ^[11].