Facilitating the spread of knowledge and innovation in professional software development

Contribute

### Topics

InfoQ Homepage News MSMQ and .NET Core

# MSMQ and .NET Core

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.

## How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

• ##### MSMQ and .NET Core

by Andrew Watts,

• ##### Re: MSMQ and .NET Core

by Jonathan Allen,

• ##### MSMQ and .NET Core

by Andrew Watts,

Your message is awaiting moderation. Thank you for participating in the discussion.

We currently uses MSMQ in our specific small system. We'd really like to see a .NET Core version. 2 Key things that stand out for MSMQ is the UX to create triggers / rules that launch an EXE by simply passing the parameters in the queue. This small touch within the UX provides great simplicity. The other aspect is the queue to restore itself on server reboot. Unfortunately despite providing those parameters, our data is being lost. We have somehow enabled a edge case bug

• ##### Re: MSMQ and .NET Core

Your message is awaiting moderation. Thank you for participating in the discussion.

Honestly, I have serious doubts about the longevity of MSMQ in general. I would recommend moving to a different queueing platform as soon as reasonable.

Almost everyone I talked to while researching this recommended RabbitMQ as the default choice.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.