Microsoft Message Queuing (MSMQ) is currently not available for .NET Core. While other message queuing systems are generally preferred, many enterprise applications were based on MSMQ and this creates a problem for teams looking to migrate from .NET Framework to .NET Core or the upcoming .NET 5. But a recent pull request for Reference Source may change the situation.
MSMQ was created in 1997 and has been available as an optional OS component since Windows 95 and Windows NT 4.0. (The current version of Windows is derived from Windows NT.) This ubiquity made it the default choice for many companies, especially in the early years where there were few competitors outside of Java’s proprietary JMS technology.
Though, accusing JMS of being proprietary is a bit misleading. While it was only available for Java, it could run on any operating system. Conversely, MSMQ was available for any COM-compatible programming language, but could only run on Windows. And for any programming language to be viable on Windows, it needed to be able to access COM libraries.
For .NET programmers, there were multiple options for working with MSMQ. The most difficult route is to use the Win32 or COM-based libraries directly. This puts the COM/.NET interop issues in the forefront. As anyone who has dealt with COM from C# can tell you, it is hard to avoid memory leaks when mixing a reference-counted library and .NET’s mark & sweep style GC.
The more popular option was a library known as System.Messaging
. This was part of the .NET Framework since the beginning. However, it hasn’t been carried over to .NET Core.
The final option was to use Windows Communication Foundation (WCF). In theory this allows messages that were previously being sent to MSMQ to be rerouted to any other message queueing system merely by changing a configuration setting. But the necessary plugins for non-Microsoft technologies were not widely available, so WCF never fulfilled that promise. And the .NET Core version of WCF is neither production ready nor does it have MSMQ on the current roadmap.
Why does this matter? In his article titled MSMQ is dead, David Boike cites two major advantages of MSMQ that need to be considered when trying to switch to a different message queueing system:
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.
Recently Karel Zikmund of Microsoft posted the original .NET Framework code for System.Messaging to Reference Source. This puts it under an MIT license and makes it possible to start working on a .NET Core implementation. If this happens, presumably it would be a community effort much like Core WCF.
According to Bill Loytty, he was able to get System.Messaging working under .NET Core. But this was before System.Messaging
was open sourced, so at the time he couldn’t publish his results.