Wie lange lässt sich MSMQ noch nutzen? ── Die Migrationsentscheidung für eine Legacy-Queue, die nicht einmal „deprecated“ ist

„Ich habe gehört, MSMQ sei eingestellt worden. Muss das System, das wir heute betreiben, sofort migriert werden?“ — wenn Sie ein bestehendes System warten, ist das das Erste, das auseinandergezogen werden muss.

Ob MSMQ (Microsoft Message Queuing) als Betriebssystemfunktion fortbesteht und ob es eine API gibt, um es aus .NET zu nutzen, sind zwei getrennte Fragen. Stand Juli 2026, dem Bezugspunkt dieses Artikels, taucht MSMQ auf den offiziellen Listen deprecated Features nicht auf und bleibt ein optionales Windows-Feature. Die Standardbibliothek System.Messaging dagegen ist ausschließlich für das .NET Framework und wurde nie auf .NET (Core und später) portiert.¹²³

Das Problem ist also nicht, dass MSMQ morgen aufhört zu funktionieren. Es ist, dass die Queue-Implementierung zum Hindernis wird, wenn Sie die Anwendung auf .NET heben.

Dieser Artikel richtet sich an die Entwickler, die Systeme mit MSMQ warten und migrieren, und an die Abteilungen für Informationssysteme, die die Linie festlegen. Er beginnt damit, die Fakten und die Bedingungen für die Weiternutzung festzuhalten, und arbeitet sich dann durch die Bestandsaufnahme, die Wahl des Migrationsziels, die Implementierung einer Tabellen-Queue und das Umschaltverfahren.

Zur Migration von VB6 oder vom .NET Framework insgesamt siehe „Wie lange laufen VB6-Anwendungen noch? — Support-Status der Laufzeitumgebung und ein praxisnaher Weg zur .NET-Migration“ und „Checkliste vor der Migration von .NET Framework zu .NET“. Dieser Artikel konzentriert sich auf die Queue.

1. Zuerst das Fazit: Das Fortbestehen des Betriebssystems von der Migration der Anwendung trennen

Wenn Sie die Anwendung auf .NET heben, gilt als Grundsatz, die Queue mit zu migrieren. Wenn Sie vorerst auf dem .NET Framework weiterlaufen, können Sie sich für die Weiternutzung von MSMQ entscheiden, sobald Sie den Supportzeitraum des Betriebssystems und die Betriebsbedingungen geprüft haben. MSMQ in einem neuen Projekt einzuführen ist nicht empfehlenswert.⁴

Lesen Sie von dem aus, was Sie jetzt entscheiden müssen

Wenn Sie den Artikel durchlesen, ist die Reihenfolge bestätigen, was fortbesteht → Bedingungen für die Weiternutzung → Bestandsaufnahme → Migrationsziel → Implementierung → Umschaltung. Wenn Sie die Entscheidung später erneut ansehen, siehe die Zusammenfassung in Kapitel 7.

1.1. Bestätigen, um welche Schicht es in der Frage geht

Die Antwort auf „kann MSMQ noch genutzt werden“ unterscheidet sich je nach Schicht wie folgt. Bezugspunkt für diese Zustände ist Juli 2026, derselbe wie am Anfang des Artikels.

1.2. Was nicht deprecated ist, ist die Betriebssystemfunktion

Die Liste „Deprecated features“ des Windows-Clients trägt Einträge wie NTLM, VBScript und WordPad, aber es gibt keinen Eintrag für MSMQ. Dasselbe gilt für „Features Removed or No Longer Developed“ von Windows Server, einschließlich der Registerkarte Windows Server 2025.¹²

Deprecated ist eine offizielle Stufe, die anzeigt, dass die aktive Entwicklung beendet ist und das Feature in einem künftigen Update entfernt werden kann. Sie ist von removed zu unterscheiden. Für MSMQ hat dieser Artikel bestätigt, dass nicht einmal diese Deprecation erklärt worden ist.

1.3. Was die Migration zu .NET blockiert, ist die Managed API

Die Referenz von System.Messaging.MessageQueue deckt .NET Framework 1.1 bis 4.8.1 ab; es gibt keine Ausgabe für .NET (Core und später). Das Windows Compatibility Pack (Microsoft.Windows.Compatibility) liefert rund 20.000 APIs und deckt Bereiche wie die Registry, WMI, Windows-Dienste und EventLog ab, enthält aber nicht System.Messaging.³⁶

Wenn Sie es mit P/Invoke am Leben halten, übernehmen Sie die Pflege des Wrappers

Auch die native API ist nicht verschwunden. Win32-APIs wie MQSendMessage und MQReceiveMessage aus .NET per P/Invoke aufzurufen, ist an sich möglich. Aber Sie werden einen eigenen Wrapper für die Formatter und die Transaktionsanbindung schreiben und pflegen, die System.Messaging geliefert hat. Das ist nicht der Hauptweg einer Migration; es ist ein Mittel, MSMQ zu verlängern, wenn Sie es unbedingt behalten müssen.⁵

1.4. CoreWCF als Weg für die WCF-Empfängerseite beurteilen

WCF im .NET Framework hatte ein Binding, das MSMQ verwendet. Als Weg, das auf .NET zu hosten, gibt es den MSMQ-Transport von CoreWCF (CoreWCF.MSMQ).⁷

Sein Zweck ist allerdings die Empfängerseite eines über eine Queue aufgerufenen WCF-Dienstes. Es ist weder eine allgemeine Queue-API, die System.Messaging ersetzt, noch ein Ersatz für den sendenden Client.

CoreWCF selbst hat eine Microsoft-Support-Richtlinie. Die Implementierung des MSMQ-Transports hängt jedoch von einer Community-Portierung der .NET-Framework-Version von System.Messaging ab, und diese Abhängigkeit kann nicht so behandelt werden, als trüge sie dieselbe Garantie. Übernehmen Sie es erst, nachdem Sie geprüft haben, ob die von Ihnen genutzte Version unter den Support fällt und wer den abhängigen Teil pflegt.⁷

„MSMQ ist bereits eingestellt“ und „es lässt sich nicht unverändert nach .NET heben“ bedeuten also nicht dasselbe. P/Invoke oder CoreWCF zu wählen, schiebt das Ersetzen der Queue hinaus, zum Preis, die Wartungslast dieses Weges zu übernehmen.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (28 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Ob Sie es weiter nutzen: Anhand des .NET-Migrationsplans und Ihrer Betriebsorganisation entscheiden

2.1. Warum „es läuft“ nicht ausreicht, um zu entscheiden

.NET Framework 4.8 wird als Windows-Komponente entlang des Lebenszyklus des Betriebssystems unterstützt, auf dem es installiert ist. Sie können daher planen, es innerhalb dieses Supportzeitraums weiterlaufen zu lassen.⁴

Was Sie feststellen wollen, ist nicht nur, ob es läuft. Wenn eine Abhängigkeit von MSMQ die ganze Anwendung auf dem .NET Framework hält, bleiben auch die folgenden Wartungs- und Migrationslasten.

Das Problem, den Maintainer zu verlieren, wird auch in „Wenn Sie ein System ohne Quellcode und ohne Dokumentation übernehmen — Ein praktisches Playbook, um es am Laufen zu halten“ behandelt. MSMQ-Anfragen beginnen eher mit einer Migrationsschätzung als mit einem Ausfall, gerade weil das, was Schwierigkeiten macht, diese Art von Abhängigkeit und Übergabe ist, nicht das Verhalten selbst.

„Es läuft, solange das Betriebssystem es unterstützt“ und „je länger Sie warten, desto leichter wird die Migration“ sind zwei verschiedene Behauptungen. Auch wenn Sie vorerst nicht migrieren, nehmen Sie die schwierigen Teile zuerst auf.

2.2. Wenn Sie vorerst nicht migrieren, erfüllen Sie vier Mindestbedingungen

Keinen Plan zu haben, die Anwendung auf .NET zu heben, und sie vorerst aus Kosten-Nutzen-Gründen unverändert zu lassen — oft als Belassen im Ist-Zustand bezeichnet — ist unter Bedingungen vernünftig. Die Voraussetzung ist allerdings, dass alle vier der folgenden Punkte erfüllt sind.

Gerade die jährliche Überprüfung ist das Verfahren, das verhindert, dass Ihnen eine Deprecation-Mitteilung oder die Wirkung eines Betriebssystemupdates entgeht. Falls die verantwortliche Person wechselt, hinterlassen Sie nicht nur die Konfiguration, sondern auch das Wiederherstellungsverfahren. Den Status quo ohne diese Bedingungen zu halten, trägt das Risiko, dass niemand mehr weiß, weder dass es gestoppt hat, noch warum.

3. Bestandsaufnahme: Festhalten, was Sie MSMQ übertragen haben

3.1. Die Funktionen und die Terminologie klären

Bei MSMQ schreibt der Sender eine Nachricht in eine Queue, und eine Anwendung auf derselben Maschine oder auf einer anderen entnimmt sie, wann es ihr passt. Es gibt vor allem drei Eigenschaften, die auf das Migrationsziel übergehen müssen.

Es sammelt sich auch, wenn das Ziel down ist: Store-and-Forward

Auch wenn das Ziel down ist, sammeln sich Nachrichten lokal und werden zugestellt, sobald es sich erholt. Das hilft auf instabilen Standort-zu-Standort-Verbindungen, garantiert aber nicht bedingungslos Dauerhaftigkeit über einen Neustart hinweg.

Es schreibt Queue und Datenbankaktualisierung gemeinsam fest: Transaktionen

Queue-Operationen können transaktional gemacht werden, und mit MS DTC (dem Distributed Transaction Coordinator) können die Entnahme aus der Queue und die Datenbankaktualisierung in einer einzigen verteilten Transaktion festgeschrieben werden.

Es war ohne zusätzliche Middleware nutzbar: Mit dem Betriebssystem ausgeliefert

Weil keine zusätzliche Middleware installiert werden musste, wurde es in den 2000er-Jahren breit für die Auftragsanbindung, die asynchrone Berichtserzeugung und die Anbindung zwischen Fertigungsschritten in der Halle genutzt. Die Kombination dieser drei Eigenschaften ist der Grund, warum es noch da ist.

Ansammlung, Dauerhaftigkeit und Transaktionen namentlich unterscheiden

Die in den Entscheidungstabellen verwendeten Begriffe werden hier ebenfalls festgelegt.⁹

„Es kann sich ansammeln, während der Empfänger down ist“ und „es übersteht einen Neustart von MSMQ oder der Maschine“ sind verschiedene Eigenschaften. Untersuchen Sie getrennt, ob Sie sich nur auf die erste stützen oder ob Sie über recoverable oder transaktionale Nachrichten auch die zweite brauchen.

3.2. Die Abhängigkeiten aus Code, Konfiguration und Betrieb ziehen

Die Bestandsaufnahme nicht bei Bibliotheksverweisen enden lassen

Suchen Sie zuerst nach Verweisen auf System.Messaging und nach den Stellen, an denen MessageQueue konstruiert wird. Das Fehlen eines solchen Verweises ist jedoch für sich kein Grund, zu schließen, dass MSMQ nicht genutzt wird. Prüfen Sie die Aufrufwege getrennt.

Pro Queue die Grundlage der Migrationsentscheidung festhalten

Nutzen Sie die folgende Tabelle, um festzuhalten, was Sie finden, eine Zeile pro Queue. Der Punkt ist nicht, abzuhaken und fertig zu sein, sondern die Ergebnisse als Grundlage für die Migrationslinie und für interne Genehmigungsunterlagen hinterlassen.

4. Migrationsziele: Nach den Eigenschaften wählen, die Sie brauchen, nicht nach einem Nachfolgeproduktnamen

4.1. Die Anforderungen mit vier Fragen sortieren

Aus den Ergebnissen der Bestandsaufnahme halten Sie die folgenden vier Punkte fest.

1. Ist die Empfängerseite ein Prozess, der Ihre eigene Geschäftsdatenbank aktualisiert?
2. Werden die Transaktions-Queue und die Datenbankaktualisierung über DTC gemeinsam festgeschrieben?
3. Sind Sender und Empfänger auf verschiedenen Maschinen oder an verschiedenen Standorten? Wird Store-and-Forward tatsächlich genutzt?
4. Wie groß ist das Nachrichtenaufkommen? Im Maßstab von einigen Tausend bis einigen Zehntausend am Tag, der für viele Fachanwendungen typisch ist, wird allein der Durchsatz der Kandidaten die Wahl kaum entscheiden.

4.2. Die erste Wahl für jede Eigenschaft

Für einen asynchronen Auftrag, der die Geschäftsdatenbank desselben Systems aktualisiert, sehen Sie zuerst eine Tabellen-Queue an. Wählen Sie einen Broker, wenn es eine Anforderung gibt, die eine Tabellen-Queue nicht erfüllen kann, etwa Zustellung an mehrere Systeme oder Routing.

Warum eine Tabellen-Queue zuerst kommt

„Sehen Sie zuerst eine Tabellen-Queue an“ ist hier nicht der Wunsch, eine Datenbank für jeden Zweck zu empfehlen. Es ist, dass für die asynchrone Verarbeitung, die dieselbe Datenbank aktualisiert, die in Fachanwendungen der MSMQ-Generation häufig ist, die Konsistenz einfach bleibt und die bestehende Sicherung, Überwachung und der Betrieb genutzt werden können.

Anforderungen, zu denen ein Broker passt, und was Sie zusätzlich entwerfen müssen

RabbitMQ und Azure Service Bus passen zu lose gekoppelter Zustellung über mehrere Systeme und mehrere Sprachen, zu Fan-out und Routing. Sie sind auch erwägenswert, wenn hoher Durchsatz erforderlich ist. Weil Queue und Geschäftsdatenbank getrennte Ressourcen werden, tragen Sie die Atomarität von MSMQ plus DTC jedoch nicht unverändert weiter: Entwerfen Sie Idempotenz und Neuversand in der Anwendung. Nehmen Sie Überwachung, Redundanz, Patches und Schulung für die neue Middleware in die Schätzung auf.

Migrieren heißt nicht immer, dass die Ansammlung während des Stopps entfallen darf

Prüfen Sie, ob Offline-Toleranz und Ansammlung, während der Empfänger gestoppt ist, Anforderungen sind, die Sie fallen lassen dürfen. Eine Cloud-Queue zu wählen, bringt lokale Ansammlung auf der Senderseite nicht automatisch mit, und der Wechsel zu Named Pipes bewahrt das Warten, während die Gegenstelle gestoppt ist, nicht in derselben Form. Wenn Sie es brauchen, geben Sie der Anwendung Neuversand und Pufferung oder behalten Sie eine Queue.

5. Die Tabellen-Queue: Queue-Operation und Geschäftaktualisierung in derselben Datenbank festschreiben

Dieses Kapitel beginnt damit, was es bedeutet, beides in eine Datenbank zu holen. Von dort sieht es nacheinander die Voraussetzungen des Entnahme-SQL, wie weit die Reihenfolge garantiert ist, die Transaktion des Workers und die Verarbeitung, die Sie für den Produktivbetrieb ergänzen an.

5.1. Warum DTC überflüssig wird

Bei MSMQ sind Queue und Datenbank getrennte Ressourcen. „Aus der Queue entnommen“ und „die Geschäftsdaten aktualisiert“ gemeinsam festzuschreiben, erforderte eine verteilte Transaktion über DTC.

Machen Sie die Queue zu einer Tabelle in derselben Datenbank wie die Geschäftsdaten, und beides wird zu Aktualisierungen dieser einen Datenbank. Entnahme, Geschäftaktualisierung und Abschlussdatensatz können in einer einzigen lokalen Transaktion festgeschrieben werden. Eine verteilte Transaktion durch eine lokale zu ersetzen, ist das Herz dieser Migration.

Nicht nur die Empfängerseite: Die Senderseite kann zur selben Zeit festschreiben

Auch auf der Senderseite können die Aktualisierung der Geschäftsdaten und das INSERT der Nachrichtenzeile in dieselbe Transaktion. Das ist das Outbox-Muster und verhindert die Inkonsistenz, dass die Geschäftsdaten aktualisiert sind, aber keine Nachricht hinausgegangen ist.

Was folgt, ist die minimale Form auf SQL Server. Der C#-Teil ist Pseudocode, der die Transaktionsgrenze zeigt; es ist keine fertige Implementierung, die unverändert ausgerollt wird.

5.2. Die Tabelle, die die Aufträge speichert

CREATE TABLE dbo.JobQueue (
    Id          BIGINT IDENTITY(1,1) PRIMARY KEY,
    Payload     NVARCHAR(MAX) NOT NULL,                    -- The body. Held as JSON
    Status      TINYINT       NOT NULL DEFAULT 0,          -- 0: pending, 1: in progress, 2: done
    EnqueuedAt  DATETIME2     NOT NULL DEFAULT SYSUTCDATETIME(),
    StartedAt   DATETIME2     NULL,                        -- Used to reclaim rows left in progress by a crash
    RetryCount  INT           NOT NULL DEFAULT 0
);
CREATE INDEX IX_JobQueue_Status ON dbo.JobQueue (Status, Id);

Payload hält den Körper als JSON, und Status unterscheidet ausstehend, in Bearbeitung und erledigt. StartedAt und RetryCount werden für die Rückhol- und Wiederholungsoperationen genutzt.

5.3. Eine Zeile entnehmen und die Datenbankeinstellungen prüfen

Die Zeile, die Sie nehmen, aktualisieren und ihren Körper in einer einzigen SQL-Anweisung holen

Zum Entnehmen aktualisieren Sie eine Zeile auf „in Bearbeitung“ und empfangen dabei den Körper über OUTPUT. READPAST überspringt Kandidaten, auf denen ein anderer Worker eine Zeilensperre hält, statt auf sie zu warten, sodass mehrere Prozesse die Arbeit teilen können.¹⁰

WITH next_job AS (
    SELECT TOP (1) *
    -- READCOMMITTEDLOCK is required on a database where READ_COMMITTED_SNAPSHOT is ON (see below).
    -- On a database where it is OFF it matches the default behavior, so leaving it in works for both
    FROM   dbo.JobQueue WITH (READPAST, UPDLOCK, READCOMMITTEDLOCK)
    WHERE  Status = 0
    ORDER  BY Id          -- Dequeue in insertion order. This is what makes it a queue
)
UPDATE next_job
SET    Status = 1, StartedAt = SYSUTCDATETIME()
OUTPUT inserted.Id, inserted.Payload;

Zuerst die Snapshot-Einstellung und die Isolationsstufe prüfen

Wenn Sie dieses SQL lesen, prüfen Sie READ_COMMITTED_SNAPSHOT und die Isolationsstufe der Sitzung.

Die offizielle Dokumentation hält fest, dass READPAST nicht unverändert angegeben werden kann, wenn READ_COMMITTED_SNAPSHOT der Datenbank ON ist und entweder die Sitzung auf READ COMMITTED steht oder die Abfrage zusätzlich den Hinweis READCOMMITTED verwendet. Die Abhilfe ist, den Hinweis READCOMMITTED zu entfernen, falls einer vorhanden ist, und READCOMMITTEDLOCK aufzunehmen.¹⁰

Die Standard-Isolationsstufe ist READ COMMITTED, daher führt das ungeprüfte Übernehmen in eine Snapshot-fähige Datenbank nicht bloß zu Blockieren — die SQL-Anweisung schlägt mit einem Fehler fehl. Azure SQL Database hat es standardmäßig ON. On-Premises kann es auch aktiviert worden sein, um Leseblockaden zu mindern, prüfen Sie also vorher.

SELECT is_read_committed_snapshot_on FROM sys.databases WHERE name = DB_NAME();

Das Entnahme-SQL oben enthält READCOMMITTEDLOCK und liest daher unabhängig von der Snapshot-Einstellung mit Sperren. Auf einer Datenbank, in der die Einstellung OFF ist, entspricht das dem Standardverhalten.¹⁰

Warum ROWLOCK nicht daneben steht und die Grenzen von READPAST

Anders als das häufig gesehene WITH (READPAST, UPDLOCK, ROWLOCK) steht ROWLOCK hier nicht daneben. Das liegt daran, dass ROWLOCK und READCOMMITTEDLOCK zur selben Gruppe von Granularitätshinweisen gehören und beide nicht für dieselbe Tabelle angegeben werden können.¹⁰

READPAST kann nur Zeilensperren überspringen, keine Seitensperren. Im Rahmen dieses Beispiels, das eine einzelne Zeile über einen TOP (1)-Index-Seek nimmt, ist Eskalation kein praktisches Problem, aber wenn Sie ROWLOCK ausgeschrieben haben wollen, bestätigen Sie, dass READ_COMMITTED_SNAPSHOT OFF ist, und lassen Sie stattdessen READCOMMITTEDLOCK weg.

5.4. Die Entnahmereihenfolge und die Reihenfolge der Aktualisierungen der Geschäftsdaten sind verschiedene Dinge

Für die Kandidatenzeilen eine Reihenfolge angeben

Wenn Sie das ORDER BY weglassen und UPDATE TOP (1) schreiben, ist unbestimmt, welche Zeile gewählt wird. TOP auf einem UPDATE ordnet die betroffenen Zeilen nicht, und allein ein Index auf (Status, Id) ist ebenfalls keine Reihenfolgegarantie. Damit alte Aufträge nicht endlos zurückgedrängt werden, gibt das Beispiel ORDER BY Id an.¹¹

Unter Parallelverarbeitung heißt zuerst heraus nicht zuerst angewendet

Trotzdem ist die Abschlussreihenfolge unter Parallelverarbeitung nicht ausgerichtet. Während Worker A Auftrag 1 verarbeitet, überspringt Worker B diese Zeile über READPAST und kann Auftrag 2 zuerst festschreiben.

Wenn die Anwendungsreihenfolge Bedeutung hat — Aktualisierungen gegen dieselbe Auftragsnummer etwa — wählen Sie eine der folgenden Möglichkeiten.

Wenn Sie keines von beiden wählen, halten Sie im Entwurf ausdrücklich fest, dass unter Parallelverarbeitung kein globales FIFO garantiert ist. Dasselbe Problem entsteht bei MSMQ, sobald Sie parallel empfangen. Was zählt, ist, nicht zu migrieren und dabei noch zu glauben, „es ist eine Queue, also kommt es der Reihe nach heraus“.

5.5. Die Transaktionsgrenze des Workers

Was Sie auf der Empfängerseite ausrichten, ist die Transaktion, die Entnahme, Aktualisierung der Geschäftsdaten und Abschlussdatensatz umfasst. Im Pseudocode unten werden den drei Operationen dieselbe Verbindung und Transaktion übergeben, und sie werden am Ende gemeinsam festgeschrieben.

while (!stoppingToken.IsCancellationRequested)
{
    using var tx = connection.BeginTransaction();

    var job = DequeueOne(connection, tx);          // The UPDATE ... OUTPUT above
    if (job is null)
    {
        tx.Commit();
        await Task.Delay(TimeSpan.FromSeconds(1), stoppingToken);  // Nothing there: wait one polling interval
        continue;
    }

    ApplyBusinessData(connection, tx, job);        // <- Update the business data (the work you actually wanted)
    MarkDone(connection, tx, job.Id);              // Status = 2

    tx.Commit();   // "Dequeue" and "business update" are committed together by this one line
}

Der entscheidende Punkt ist, dass DequeueOne, ApplyBusinessData und MarkDone dieselbe Verbindung und Transaktion nutzen und dass das abschließende Commit Entnahme und Geschäftaktualisierung gemeinsam festschreibt. Wenn Sie das durch einen Broker ersetzen, geht diese Eigenschaft derselben Datenbank verloren, und ein anderer Konsistenzentwurf wird nötig.

5.6. Rückholung, Wiederholung und Aufräumen, die Sie für den Produktivbetrieb ergänzen

Über dem Minimalbeispiel entwerfen Sie die folgenden Operationen.

In kleinen und mittleren Fachanwendungen reichen eine Tabelle plus Polling oder eine benachrichtigungsgetriebene Variante oft. Bevor Sie ein weiteres Queue-Produkt hinzufügen, prüfen Sie, ob diese Implementierung die benötigten Eigenschaften und den benötigten Betrieb bereits erfüllt.

6. Umschaltung: Zuerst Format, Verhalten und Empfängerseite ausrichten

Für die Umschaltung richten Sie zuerst das Nachrichtenformat und die Tests über Eingaben und Ergebnisse aus. Danach wählen Sie zwischen Altes und Neues überbrücken und die alte Queue leeren, bevor Sie umschalten.

6.1. Ein Nachrichtenformat festlegen, in dem Altes und Neues koexistieren können

Machen Sie JSON nach der Migration zum Standard. Was Sie nicht mitnehmen, ist BinaryFormatter-basierte Serialisierung wie BinaryMessageFormatter. Die BinaryFormatter-Implementierung wurde in .NET 9 aus der Laufzeit entfernt und ist auch aus Sicherheitsgründen nicht empfohlen.⁸

Das heißt allerdings nicht, dass jedes Binärformat ausgeschieden ist. Formate, deren Spezifikation unabhängig gepflegt wird, etwa Protocol Buffers und MessagePack, können unverändert ins neue System übernommen werden. Legen Sie Formatter und Körpertyp zuerst in der Bestandsaufnahme in Abschnitt 3.2 fest.

6.2. Bevor Sie umschreiben, Eingaben und Ergebnisse mit Tests festnageln

Queue-Verarbeitung ist ein Bereich, in dem zeitabhängige Fehler leicht entstehen. Bereiten Sie Charakterisierungstests vor, die sagen „diese Eingabenachricht erzeugt dieses Ergebnis“, damit Sie mechanisch prüfen können, dass der Ersatz dasselbe Ergebnis liefert. Siehe auch „Eine Legacy-Business-Anwendung ohne Tests sicher verändern ── Charakterisierungstests und Refactoring in der Praxis“.

6.3. Zuerst die Empfängerseite behandeln und die Brücke um Verlust und Duplikate herum entwerfen

Zuerst die Empfängerseite herüberholen

Zuerst stellen Sie die neue Queue bereit, bringen die Empfängerseite dagegen zum Laufen und schalten erst dann die Senderseite um.

Eine kleine Brücke einzusetzen, die Nachrichten vom alten MSMQ in die neue Queue bewegt, erspart Ihnen, jeden Sender auf einmal umzuschalten. Die Brücke selbst kann auf dem .NET Framework bleiben.

Das Übergabeverfahren danach trennen, ob Transaktionen genutzt werden

Aber wenn es zwischen dem Entnehmen aus MSMQ und dem Schreiben in die neue Queue stoppt, erhalten Sie entweder Verlust oder Doppelzustellung. Entwerfen Sie wie folgt, je nach Art der Quellqueue.

Das transaktionale Attribut einer Queue wird bei der Erstellung festgelegt und kann danach nicht geändert werden. Beachten Sie, dass das transaktionale Empfangsverfahren nicht einfach auf eine nicht transaktionale Queue angewendet werden kann.

6.4. Wenn die Brücke sich nicht lohnt, die Queue leeren und umschalten

Wenn die Maßnahmen gegen Verlust und Duplikate in der Brücke außer Verhältnis zur Größe des Systems stehen, erzwingen Sie nicht das Nebeneinander von Alt und Neu; neigen Sie dazu, die alte Queue in einer geplanten Unterbrechung zu leeren und dann umzuschalten.

Umschalten, während noch Nachrichten in der Queue sitzen, verursacht Doppelverarbeitung und Verlust. Die Queue vor dem Umschalten zu leeren ist am Ende oft der sicherste und schnellste Weg — das ist das praktische Urteil dieses Artikels.

7. Zusammenfassung

Stand Juli 2026, dem Bezugspunkt dieses Artikels, ist MSMQ offiziell nicht deprecated. Als Betriebssystemfunktion fortzubestehen und leicht nach .NET zu migrieren sind zwei verschiedene Dinge. System.Messaging ist auf das .NET Framework beschränkt, daher gilt als Grundsatz: Wenn Sie die Anwendung auf .NET heben, überprüfen Sie die Queue mit.¹²³

Wenn Sie es vorerst weiter nutzen, prüfen Sie den Supportzeitraum des Betriebssystems und richten Sie Aufbau- und Wiederherstellungsverfahren, Queue-Überwachung, eine Aufzeichnung der Konfiguration und eine jährliche Überprüfung der Entscheidung ein. Das große Risiko des Belassens im Ist-Zustand ist nicht nur technisch: Es ist, dass niemand mehr da ist, der es anfassen kann.

Wenn Sie migrieren, nehmen Sie zuerst Abhängigkeiten und Nachrichtenformate auf. Für asynchrone Verarbeitung, die dieselbe Geschäftsdatenbank aktualisiert, ist eine Tabellen-Queue die erste Wahl. Die Konsistenz, die MSMQ plus DTC geliefert haben, kann durch eine lokale Transaktion in dieser einen Datenbank ersetzt werden. Ziehen Sie RabbitMQ oder Azure Service Bus in Betracht, wenn es eine Anforderung gibt, die sie nicht erfüllen kann, etwa Zustellung an mehrere Systeme oder Routing.

Darüber hinaus prüfen Sie die SQL-Isolationsstufe und Hinweise, die Reihenfolge, in der Aktualisierungen unter Parallelität angewendet werden, und die Maßnahmen gegen Verlust und Duplikate in der Brücke. Was zählt, ist nicht zu hetzen, weil „es angeblich eingestellt worden ist“, sondern zu verstehen, wovon Ihr eigenes System abhängt, und auf dieser Grundlage zwischen Behalten und Migrieren zu entscheiden.

Verwandte Artikel

• Wie lange laufen VB6-Anwendungen noch? — Support-Status der Laufzeitumgebung und ein praxisnaher Weg zur .NET-Migration
• Checkliste vor der Migration von .NET Framework zu .NET
• Eine Legacy-Business-Anwendung ohne Tests sicher verändern ── Charakterisierungstests und Refactoring in der Praxis
• Windows-Prozesskommunikation richtig wählen ── Eine Entscheidungstabelle für Named Pipes / TCP / gRPC / Shared Memory / COM
• Der Irrglaube, man könne über TCP pro Send genau eine Einheit empfangen ── Empfangslogik entwerfen, die es als Bytestrom behandelt
• Wenn Sie ein System ohne Quellcode und ohne Dokumentation übernehmen — Ein praktisches Playbook, um es am Laufen zu halten
• Das Datenbankschema Ihrer Business-Anwendung versionieren ── Migrationspraxis gegen „jeder Kunde hat eine andere Datenbank“

Verwandte Beratungsleistungen

KomuraSoft LLC übernimmt Bestandsaufnahmen und Migrationspläne für Legacy-Konfigurationen einschließlich MSMQ, die Migration von .NET Framework zu .NET und die Überarbeitung von Fachanwendungen mit Queue-Verarbeitung.

• Weiternutzung und Migration von Altbeständen
• Wartung und Weiterentwicklung bestehender Windows-Software
• Windows-Anwendungsentwicklung
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wurde MSMQ eingestellt?

Nein. Stand Juli 2026 taucht MSMQ weder in der Liste der deprecated Features des Windows-Clients noch in der Windows-Server-Liste „Entfernte Features / nicht mehr weiterentwickelte Features“ auf. Es wird nach wie vor als optionales Windows-Feature mit den aktuellen Betriebssystemversionen ausgeliefert. Dass sich die Behauptung „eingestellt“ trotzdem verbreitet hat, liegt daran, dass sie mit der Situation auf der .NET-Seite verwechselt wird. System.Messaging, die Standardklassenbibliothek für den Umgang mit MSMQ, existiert nur im .NET Framework und wurde nie auf .NET (Core und neuer) portiert. Genau genommen gilt also: Als Betriebssystemfunktion besteht es fort, aber es gibt keinen offiziellen Weg, es aus modernem .NET zu nutzen.

Gibt es keinen Weg, MSMQ aus .NET 8 oder .NET 10 zu nutzen?

Es gibt keine offizielle Managed API. System.Messaging ist eine API bis .NET Framework 4.8.1 und ist auch nicht im Windows Compatibility Pack (Microsoft.Windows.Compatibility) enthalten. Die native Win32-API von MSMQ (etwa MQSendMessage) per P/Invoke aufzurufen, ist technisch möglich, bedeutet aber, den Bau und die Pflege eines eigenen Wrappers samt Formatter und Transaktionsanbindung zu übernehmen. Auf der Community-Seite veröffentlicht das CoreWCF-Projekt ein Paket für den MSMQ-Transport (CoreWCF.MSMQ), aber das dient dazu, über eine Queue aufgerufene WCF-Dienste auf modernem .NET zu hosten (eine Portierung der Serverseite von WCF) — es ist weder eine allgemeine Queue-API als Ersatz für System.Messaging noch ein Ersatz für den sendenden Client. Die Implementierung hängt zudem von einer Community-Portierung des System.Messaging der .NET-Framework-Version ab. Für Evaluierung oder eine vorübergehende Lebensverlängerung ist es eine gangbare Option. CoreWCF selbst besitzt eine offizielle Support-Richtlinie von Microsoft, doch diese Garantie erstreckt sich nicht automatisch auf die Community-Portierung von System.Messaging, von der diese MSMQ-Implementierung abhängt. Wenn Sie ein Produktivsystem darauf aufbauen wollen, sollten Sie deshalb erst prüfen, ob die verwendete Version unter die Support-Richtlinie fällt und wie mit dem abhängigen Teil umgegangen wird. In der Praxis ist es der richtige Weg, die Queue zu demselben Zeitpunkt zu migrieren, zu dem Sie die Anwendung auf .NET heben.

Was eignet sich besser als Migrationsziel — RabbitMQ oder Azure Service Bus?

Bevor Sie sich zwischen den beiden entscheiden, prüfen Sie zunächst, ob sich eine Datenbanktabelle als Queue eignet. Bei den meisten kleinen und mittleren Fachanwendungen, die MSMQ verwenden, ist die Gegenstelle der Queue ein Prozess, der die eigene Datenbank aktualisiert. In diesem Fall lässt sich mit einer Tabellen-Queue „das Entnehmen der Nachricht“ und „die Aktualisierung der Geschäftsdaten“ in derselben lokalen Transaktion wie die Geschäftsdaten festschreiben — das ersetzt die Konsistenz, die MSMQ zusammen mit einer verteilten Transaktion (DTC) geliefert hat, durch einen deutlich einfacheren Mechanismus. Erst wenn eine Tabellen-Queue für eine Anforderung nicht ausreicht — etwa lose gekoppelte Zustellung zwischen mehreren Systemen oder ein Bedarf an hohem Durchsatz —, sollten Sie RabbitMQ in Betracht ziehen, falls die Anforderung stark On-Premises geprägt ist, oder Azure Service Bus, falls sich das in die Cloud verlagern lässt. Diese Reihenfolge scheitert am seltensten.

Ist die Entscheidung vertretbar, vorerst bei .NET Framework zu bleiben und es unangetastet zu lassen?

Unter Bedingungen: ja. .NET Framework 4.8 wird als Windows-Komponente entlang des Lebenszyklus des Betriebssystems unterstützt, und auch MSMQ selbst ist nicht deprecated, sodass Sie realistisch davon ausgehen können, dass es „weiterläuft“. Wenn Sie sich trotzdem für das unangetastete Belassen entscheiden, sollten Sie mindestens diese vier Dinge tun: die Aktivierung des MSMQ-Features im Kitting-Verfahren ausdrücklich festhalten, eine Überwachung von Warteschlangenlänge und Journal einrichten, Nachrichtenformat und Verbindungskonfiguration dokumentieren, sowie ein Wiederherstellungsverfahren hinterlegen, falls der zuständige Mitarbeiter wechselt. Das eigentliche Risiko des unangetasteten Belassens ist nicht technischer Natur — es ist, dass niemand mehr da ist, der sich damit auskennt.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.