Worth separating two things happening on the same date, because only one of them breaks your code.
The SDK retirement means WindowsAzure.ServiceBus stops receiving support and security updates. Your code keeps running.
The SBMP protocol retirement is different — after 30 September 2026 the service refuses SBMP connections outright, at the network level.
Which one hits you depends on your connection. WindowsAzure.ServiceBus 2.1 and later can use AMQP 1.0, but it's opt-in and plenty of deployments never enabled it. If your QueueClient is still on SBMP, you have a hard outage on that date. If you're already on AMQP, you have an unsupported library, which is a different and less urgent problem. I'd establish that first, because it decides your timeline.
On the migration itself, I wouldn't reference Azure.Messaging.ServiceBus directly from X++ even once it resolves. It's async-first, so Task-based APIs from X++ mean GetAwaiter().GetResult() everywhere, which is where deadlocks come from. And it pulls a substantial dependency tree with Azure.Core and friends, which brings assembly binding questions you can't easily resolve in a cloud-hosted environment.
What I'd do instead is a C# class library in the same solution. Reference the NuGet package there, expose a small synchronous facade — SendMessage(queue, payload) — and call that from X++. The dependency tree and the async model both stay inside the library.
Stepping back though: is X++ the right place for this at all? Business events support Azure Service Bus queue and topic as first-party endpoint types, both with their own Microsoft documentation, so this isn't something you'd build. It also changes your credential story — the endpoint authenticates through Key Vault and an Entra application rather than a connection string sitting in X++. If you're sending messages in response to something happening in F&O, that removes the SDK dependency entirely and the retirement stops being your problem.
On whether the platform will ship Azure.Messaging.ServiceBus as a reference — I don't know, and I'd put that to Microsoft directly rather than the forum. If you're an ISV it matters a lot, since packaging your own copy of a common SDK creates version conflicts with anyone else doing the same.
Share
Report
252
All responses (
Answers (
