MSMQ is dead

We gather here today to mourn the passing of a dear friend. Microsoft Message Queuing, better known by its nickname MSMQ, passed away peacefully in its hometown of Redmond, Washington on October 14, 2019, at the age of 22. It was born in May 1997 and through 6.3 versions lived a very full life, bringing the promise of reliable messaging patterns to users all around the globe. It is preceded in death by Windows Communication Foundation and Windows Workflow Foundation, and survived by Azure Queues and Azure Service Bus. It will be greatly missed.

🔗Ok, but seriously…

So MSMQ isn’t dead as a doornail dead. As a Windows component, MSMQ is technically “supported” as long as it’s carried by a supported version of Windows. Since it exists in Windows 10 and Windows Server 2019, MSMQ will continue to live on until at least 2029—and much longer assuming it isn’t removed from future versions of Windows. The System.Messaging namespace lives on in .NET Framework 4.8 (which will be its last release ever, being completely supplanted by .NET 5), so likewise that is likely to be supported for decades to come.

But make no mistake. For all practical purposes, MSMQ is dead.

The real cause of MSMQ’s demise is .NET Core. On October 14, 2019, Microsoft announced that .NET Core 3.0 concludes the .NET Framework API porting project, and closed the issue for adding .NET Core support for the System.Messaging namespace. But even before the official announcement, Damian Edwards basically said as much at an NDC Oslo panel discussion on the future of .NET in June 2019.

According to Microsoft, .NET Core is the future of .NET:

New applications should be built on .NET Core. .NET Core is where future investments in .NET will happen. Existing applications are safe to remain on .NET Framework which will be supported. Existing applications that want to take advantage of the new features in .NET should consider moving to .NET Core. As we plan into the future, we will be bringing in even more capabilities to the platform.

So as a company dedicated to making our customers better at building, maintaining, and running complex software systems, it’s basically impossible for us to recommend building a new system using MSMQ.

🔗So what do I need to do?

What if you have a current system already running on MSMQ? What do you do then? First of all…

If you’re comfortable with your system continuing to run on .NET Framework, then you don’t really need to do anything. Microsoft will continue to support MSMQ for years and years, as long as you don’t care about any of the improvements promised in .NET 5 and beyond.

If you do want to stay with the times, and your MSMQ system happens to run on NServiceBus, you’re already a bit ahead of the curve. The NServiceBus API gives you an abstraction away from the raw MSMQ API, making it quite a bit easier to transition to some other message transport than if you’d written directly against MSMQ to start with.

The first thing you’ll need to do is select an alternate message transport. Microsoft would of course prefer you use MSMQ’s younger sibling, Azure Service Bus, but there are a lot of other options out there. We have a resource to help you make a decision in our documentation.

Once you’ve selected a transport, there are a few main things to keep in mind when considering a move off MSMQ:

• MSMQ is a distributed or federated messaging system where every server hosts the queue infrastructure, and outgoing messages are sent locally before being delivered to their ultimate address. In contrast, most other messaging systems are centralized or broker-based, meaning there is only one logical queue system, which usually exists in a cluster to provide for high availability. This makes scale-out quite a bit easier as multiple physical endpoint instances can both compete for messages on the same queue using the competing consumers pattern.
• MSMQ was fairly unique in that it supported distributed transactions, meaning that database operations in SQL Server and messaging operations through the queues could all be combined in one atomic transaction so that either everything succeeded, or everything failed. Most other message transports do not support distributed transactions, but if you’re using NServiceBus, we have a component called the Outbox that simulates the reliability of a distributed transaction by piggybacking on a local database transaction. See our blog post What does idempotent mean? for more details.
• It’s preferred to gradually move a system from one transport to another while bridging between them. This can be done with the Messaging Bridge Pattern and if you use NServiceBus, the NServiceBus Messaging Bridge.

Our solution architects are ready to help you come up with the best strategy for your specific situation. Contact us any time and we’ll talk.

🔗Our future plans

As far as Particular Software is concerned, we don’t yet have any concrete plans to discontinue our own support for MSMQ systems.

At this time, you can still build and maintain NServiceBus systems with the MSMQ transport using NServiceBus version 7, which targets .NET Framework 4.5.2+ and .NET Standard 2.0, which we will support for as long as NServiceBus 7 is supported.

While we don’t have any immediate plans to do so, the most likely event that would affect our support for MSMQ would be the release of a new major version of NServiceBus where we felt we needed to drop support for the .NET Framework altogether. However, our goal is to be backward compatible for as long as possible.

Once we released a major version of NServiceBus without MSMQ, according to our support policy the previous major version of NServiceBus would have mainstream support for all customers for 2 additional years, with an opportunity to purchase extended support for 2 additional years after that.

However, it bears repeating: We don’t have any concrete plans to start that process yet. NServiceBus will still be supporting MSMQ systems for some time to come.

🔗But what about open source?

One attempt has already been made to create a .NET Core version of System.Messaging using code harvested from .NET Framework reference source code. So, why not attempt to use that to create a .NET Core version of the NServiceBus MSMQ transport?

First, the license for that code only covers reference use, meaning “use of the software within your company as a reference, in read only form, for the sole purposes of debugging your products, maintaining your products, or enhancing the interoperability of your products with the software, and specifically excludes the right to distribute the software outside of your company.”

Even if that weren’t so, or if Microsoft were to make System.Messaging available under the MIT license, our customers value the reliability they get from our software, and the support guarantees we have in place to back that up. The risk of taking ownership of that code, in order to support our customers, would be too great.

And it wouldn’t be the same anyway. As noted above, one of the defining characteristics of MSMQ was its support of distributed transactions, which aren’t supported in .NET Core. Users would need to make significant changes to their systems just to account for this—it would by no means be a smooth transition. We don’t think it’s likely that companies would take that risk (if available) knowing that Microsoft has already rung the bells for MSMQ’s funeral.

🔗Summary

In 2007, the very first version of NServiceBus was a wrapper around MSMQ. Support for other message transports was added through the years. MSMQ is an important part of our history, so we have mixed feelings about its passing.

But we feel a measure of relief as well, because for about a year the future of MSMQ was murky at best. Customers would ask us if MSMQ was dead and we would answer that honestly, we don’t know. It might be a bit painful, but at the very least Microsoft’s announcement gives some certainty and finality to that question, so that we can all move forward.

Breaking up is hard to do, but for all practical purposes, MSMQ is gone and it’s time to move on.

Rest in peace MSMQ. So long and thanks for all the fish.

About the author: David Boike is a developer at Particular Software who began his journey with distributed systems and messaging a decade ago with MSMQ and NServiceBus 2.0. It’s been quite the ride.