¿Hasta cuándo se puede usar MSMQ? — La decisión de migración de una cola legacy que «ni siquiera está en desuso»

«He oído que MSMQ se ha discontinuado. ¿El sistema que tenemos en marcha hoy tiene que migrarse de inmediato?» — cuando se mantiene un sistema existente, esto es lo primero que hay que desentrañar.

Que MSMQ (Microsoft Message Queuing) sobreviva como función del sistema operativo y que exista una API para usarlo desde .NET son dos preguntas distintas. A fecha de julio de 2026, el punto de referencia de este artículo, MSMQ no aparece en las listas oficiales de funciones en desuso y sigue siendo una función opcional de Windows. La biblioteca estándar System.Messaging, en cambio, es exclusiva de .NET Framework y nunca se portó a .NET (Core y posteriores).¹²³

Así que el problema no es que MSMQ deje de funcionar mañana. Es que la implementación de la cola se convierte en el obstáculo cuando se sube la aplicación a .NET.

Este artículo está escrito para los desarrolladores que mantienen y migran sistemas que usan MSMQ, y para los departamentos de sistemas de información que fijan la política. Empieza por establecer los hechos y las condiciones de uso continuado, y después recorre el inventario, la elección del destino de migración, la implementación de una cola de tabla y el procedimiento de corte.

Para la migración desde VB6 o desde .NET Framework en conjunto, véase «¿Hasta cuándo seguirán funcionando las aplicaciones VB6? — Estado del soporte del runtime y un camino práctico hacia la migración a .NET» y «Lista de verificación previa a la migración de .NET Framework a .NET». Este artículo se centra en la cola.

1. Primero la conclusión: separar la supervivencia del sistema operativo de la migración de la aplicación

Si sube la aplicación a .NET, la norma es migrar también la cola. Si por el momento sigue en .NET Framework, puede optar por seguir usando MSMQ una vez comprobado el periodo de soporte del sistema operativo y las condiciones de operación. Adoptar MSMQ en un proyecto nuevo no se recomienda.⁴

Lea desde lo que necesita decidir ahora

Si lee el artículo de cabo a rabo, el orden es confirmar qué sobrevive → condiciones de uso continuado → inventario → destino de migración → implementación → corte. Cuando vuelva a la decisión más adelante, véase el resumen del capítulo 7.

1.1. Confirmar de qué capa habla la pregunta

La respuesta a «¿se puede seguir usando MSMQ?» difiere por capa, como sigue. El punto de referencia de estos estados es julio de 2026, el mismo que al inicio del artículo.

1.2. Lo que no se ha puesto en desuso es la función del sistema operativo

La lista «Deprecated features» del cliente Windows incluye entradas como NTLM, VBScript y WordPad, pero no hay una entrada para MSMQ. Lo mismo vale para «Features Removed or No Longer Developed» de Windows Server, incluida la pestaña de Windows Server 2025.¹²

Deprecated es una etapa oficial que indica que el desarrollo activo ha terminado y que la función puede eliminarse en una actualización futura. Se distingue de removed. En el caso de MSMQ, lo que este artículo ha confirmado es que ni siquiera se ha declarado ese desuso.

1.3. Lo que bloquea la migración a .NET es la API administrada

La referencia de System.Messaging.MessageQueue cubre .NET Framework 1.1 a 4.8.1; no hay una edición para .NET (Core y posteriores). El paquete de compatibilidad de Windows (Microsoft.Windows.Compatibility) aporta unas 20.000 API, que cubren áreas como el Registro, WMI, los servicios de Windows y EventLog, pero no incluye System.Messaging.³⁶

Si lo mantiene vivo con P/Invoke, asume el mantenimiento del contenedor

La API nativa tampoco ha desaparecido. Llamar desde .NET, mediante P/Invoke, a API Win32 como MQSendMessage y MQReceiveMessage es posible en sí. Pero estará escribiendo y manteniendo su propio contenedor para los formateadores y la integración transaccional que aportaba System.Messaging. Esta no es la vía principal de una migración; es una forma de prorrogar la vida de MSMQ cuando tiene que conservarlo a toda costa.⁵

1.4. Juzgar CoreWCF como vía para el lado receptor de WCF

WCF en .NET Framework tenía un enlace que usa MSMQ. Como vía para hospedarlo en .NET, existe el transporte MSMQ de CoreWCF (CoreWCF.MSMQ).⁷

Su propósito, sin embargo, es el lado receptor de un servicio WCF invocado a través de una cola. No es una API de cola de propósito general que sustituya a System.Messaging ni un sustituto del cliente emisor.

CoreWCF en sí tiene una política de soporte de Microsoft. La implementación del transporte MSMQ, en cambio, depende de un port comunitario de la versión de .NET Framework de System.Messaging, y esa dependencia no puede tratarse como si llevara la misma garantía. Adóptelo solo después de comprobar si la versión que usa está cubierta por el soporte y quién mantendrá la pieza dependiente.⁷

Así, «MSMQ ya se ha discontinuado» y «no se puede pasar tal cual a .NET» no significan lo mismo. Elegir P/Invoke o CoreWCF aplaza la sustitución de la cola a cambio de asumir la carga de mantenimiento de esa vía.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (28 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Si seguir usándolo: decidir a partir del plan de migración a .NET y de su dispositivo de operación

2.1. Por qué «funciona» no basta para decidir

.NET Framework 4.8 recibe soporte como componente de Windows, siguiendo el ciclo de vida del sistema operativo en el que está instalado. Por tanto, puede planear seguir haciéndolo funcionar dentro de ese periodo de soporte.⁴

Lo que quiere establecer no es solo si funciona. Si una dependencia de MSMQ retiene toda la aplicación en .NET Framework, también quedan las siguientes cargas de mantenimiento y de migración.

El problema de perder al responsable de mantenimiento también se trata en «Cuando hereda un sistema sin código fuente ni documentación — Procedimiento práctico para operarlo y mantenerlo sin detenerlo». Las consultas sobre MSMQ tienden a empezar por una estimación de migración más que por un fallo precisamente porque lo que causa problemas es este tipo de dependencia y de entrega, más que el comportamiento en sí.

«Funciona mientras el sistema operativo lo soporte» y «cuanto más se espera, más fácil se vuelve la migración» son dos afirmaciones distintas. Aunque no migre por ahora, inventaríe primero las partes difíciles.

2.2. Si no migra por ahora, cumpla cuatro condiciones mínimas

No tener un plan para subir la aplicación a .NET y dejarla sin cambios por el momento por razones de coste-beneficio —lo que a menudo se llama dejarlo congelado— es razonable bajo condiciones. La premisa, no obstante, es que se cumplan las cuatro siguientes.

La revisión anual en particular es el procedimiento que impide que se le escape un aviso de desuso o el efecto de una actualización del sistema operativo. Por si la persona responsable se marcha, deje no solo la configuración sino también el procedimiento de recuperación. Mantener el statu quo sin cubrir estas condiciones conlleva el riesgo de que nadie sepa ni que se detuvo ni por qué.

3. Inventario: registrar qué ha delegado en MSMQ

3.1. Dejar claras las funciones y la terminología

Con MSMQ, el emisor escribe un mensaje en una cola y una aplicación en la misma máquina o en otra lo extrae cuando le conviene. Hay principalmente tres propiedades que tienen que pasar al destino de migración.

Se acumula incluso cuando el destino está caído: store-and-forward

Aunque el destino esté caído, los mensajes se acumulan en local y se entregan cuando se recupera. Eso ayuda en enlaces inestables entre sedes, pero no garantiza de forma incondicional la durabilidad a través de un reinicio.

Confirma juntas la cola y la actualización de la base: transacciones

Las operaciones de cola pueden hacerse transaccionales y, con MS DTC (el Coordinador de transacciones distribuidas), la extracción de la cola y la actualización de la base pueden confirmarse en una sola transacción distribuida.

Se podía usar sin instalar middleware adicional: incluido con el sistema operativo

Como no había que instalar middleware adicional, se usó ampliamente en la década de 2000 para la integración de pedidos, la generación asíncrona de informes y la integración entre etapas de fabricación en planta. La combinación de estas tres propiedades es la razón de que siga existiendo.

Distinguir por nombre la acumulación, la durabilidad y las transacciones

Los términos usados en las tablas de decisión también se fijan aquí.⁹

«Puede acumularse mientras el receptor está caído» y «sobrevive a un reinicio de MSMQ o de la máquina» son propiedades distintas. Investigue por separado si se apoya solo en la primera o si también necesita la segunda mediante mensajes recoverable o transaccionales.

3.2. Sacar las dependencias del código, la configuración y la operación

No deje que el inventario termine en las referencias de biblioteca

Empiece por buscar referencias a System.Messaging y los sitios donde se construye MessageQueue. La ausencia de esa referencia, sin embargo, no es por sí sola motivo para concluir que no se usa MSMQ. Compruebe las vías de llamada por separado.

Registrar, por cola, la base de la decisión de migración

Use la tabla siguiente para registrar lo que encuentre, una fila por cola. El punto no es marcar y dar por cerrado, sino dejar los resultados como base de la política de migración y de los documentos de aprobación interna.

4. Destinos de migración: elegir por las propiedades que necesita, no por el nombre de un producto sucesor

4.1. Ordenar los requisitos con cuatro preguntas

A partir de los resultados del inventario, establezca los cuatro puntos siguientes.

1. ¿El lado receptor es un proceso que actualiza su propia base de datos de negocio?
2. ¿La cola transaccional y la actualización de la base se confirman juntas a través de DTC?
3. ¿El emisor y el receptor están en máquinas o sedes distintas? ¿Se usa de verdad store-and-forward?
4. ¿Qué volumen de mensajes hay? En la escala de unos miles a unas decenas de miles al día, típica de muchos sistemas de negocio, el solo rendimiento de los candidatos difícilmente zanja la elección.

4.2. La primera opción para cada propiedad

Para un trabajo asíncrono que actualiza la base de negocio del mismo sistema, mire primero una cola de tabla. Elija un bróker cuando hay un requisito que una cola de tabla no puede cubrir, como la entrega a varios sistemas o el enrutado.

Por qué una cola de tabla aparece primero

«Mire primero una cola de tabla» no es aquí el deseo de recomendar una base de datos para cada propósito. Es que, para el procesamiento asíncrono que actualiza la misma base, habitual en los sistemas de negocio de la era MSMQ, la consistencia se mantiene simple y se pueden aprovechar la copia de seguridad, el monitoreo y la operación existentes.

Requisitos a los que conviene un bróker, y lo que hay que diseñar encima

RabbitMQ y Azure Service Bus convienen a la entrega débilmente acoplada entre varios sistemas y varios lenguajes, al abanico y al enrutado. También merecen consideración cuando se requiere un rendimiento alto. Como la cola y la base de negocio pasan a ser recursos separados, no lleve tal cual la atomicidad de MSMQ más DTC: diseñe idempotencia y reenvío en la aplicación. Incluya en la estimación el monitoreo, la redundancia, los parches y la formación del personal para el middleware nuevo.

Migrar no siempre significa que se pueda abandonar la acumulación durante la parada

Compruebe si la tolerancia offline y la acumulación mientras el receptor está detenido son requisitos que se le permite abandonar. Elegir una cola en la nube no trae automáticamente acumulación local en el lado emisor, y pasar a canalizaciones con nombre no conserva la espera mientras el par está detenido de la misma forma. Si lo necesita, dé a la aplicación reenvío y almacenamiento intermedio, o conserve una cola.

5. La cola de tabla: confirmar la operación de cola y la actualización de negocio en la misma base

Este capítulo empieza por lo que significa reunir ambas en una sola base. A partir de ahí mira por turno las premisas del SQL de extracción, hasta dónde se garantiza el orden, la transacción del worker y el procesamiento que se añade para producción.

5.1. Por qué DTC deja de ser necesario

Con MSMQ, la cola y la base son recursos separados. Confirmar juntas «extraído de la cola» y «actualizados los datos de negocio» exigía una transacción distribuida a través de DTC.

Haga de la cola una tabla de la misma base que los datos de negocio y ambas pasan a ser actualizaciones de esa única base. La extracción, la actualización de negocio y el registro de finalización se pueden confirmar en una sola transacción local. Sustituir una transacción distribuida por una local es el corazón de esta migración.

No solo el lado receptor: el lado emisor también puede confirmar al mismo tiempo

En el lado emisor también, la actualización de los datos de negocio y el INSERT de la fila del mensaje pueden ir en la misma transacción. Este es el patrón outbox y evita la inconsistencia en la que los datos de negocio se han actualizado pero no ha salido ningún mensaje.

Lo que sigue es la forma mínima en SQL Server. La parte de C# es pseudocódigo que muestra el límite de la transacción; no es una implementación terminada para desplegar tal cual.

5.2. La tabla que almacena los trabajos

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 retiene el cuerpo como JSON y Status distingue pendiente, en curso y hecho. StartedAt y RetryCount se usan para las operaciones de recuperación y reintento.

5.3. Extraer una fila y comprobar la configuración de la base

Actualizar la fila que toma y obtener su cuerpo en una sola instrucción SQL

Para extraer, actualice una fila a «en curso» al tiempo que recibe el cuerpo mediante OUTPUT. READPAST salta los candidatos sobre los que otro worker tiene un bloqueo de fila en lugar de esperarlos, lo que permite que varios procesos compartan el trabajo.¹⁰

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;

Comprobar primero la opción de instantánea y el nivel de aislamiento

Cuando lea este SQL, compruebe READ_COMMITTED_SNAPSHOT y el nivel de aislamiento de la sesión.

La documentación oficial indica que, cuando el READ_COMMITTED_SNAPSHOT de la base está en ON y o bien la sesión está en READ COMMITTED o bien la consulta usa también la sugerencia READCOMMITTED, no se puede especificar READPAST tal cual. El remedio es quitar la sugerencia READCOMMITTED si hay una e incluir READCOMMITTEDLOCK.¹⁰

El nivel de aislamiento predeterminado es READ COMMITTED, así que llevar esto a una base con instantáneas activadas sin precauciones no se limita a bloquear: la instrucción SQL falla con un error. Azure SQL Database lo tiene ON de forma predeterminada. En local también puede haberse activado para aliviar el bloqueo de lectura, así que compruebe antes de empezar.

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

El SQL de extracción de arriba incluye READCOMMITTEDLOCK y por tanto lee con bloqueos con independencia de la opción de instantánea. En una base donde la opción está en OFF, eso coincide con el comportamiento predeterminado.¹⁰

Por qué ROWLOCK no figura al lado y los límites de READPAST

A diferencia del WITH (READPAST, UPDLOCK, ROWLOCK) que se ve a menudo, aquí no figura ROWLOCK al lado. Eso se debe a que ROWLOCK y READCOMMITTEDLOCK pertenecen al mismo grupo de sugerencias de granularidad y no se pueden especificar ambas para la misma tabla.¹⁰

READPAST solo puede saltar bloqueos de fila; no puede saltar bloqueos de página. Dentro del alcance de este ejemplo, que toma una sola fila mediante un seek de índice TOP (1), la escalada no es una preocupación práctica, pero si quiere ROWLOCK escrito, confirme que READ_COMMITTED_SNAPSHOT está en OFF y quite READCOMMITTEDLOCK en su lugar.

5.4. El orden de extracción y el orden de las actualizaciones de los datos de negocio son cosas distintas

Especificar un orden para las filas candidatas

Si quita el ORDER BY y escribe UPDATE TOP (1), qué fila se elige es indefinido. El TOP de un UPDATE no ordena las filas que toca, y el solo hecho de tener un índice en (Status, Id) tampoco es garantía de orden. Para evitar que los trabajos antiguos se aplacen de forma indefinida, el ejemplo especifica ORDER BY Id.¹¹

En procesamiento paralelo, primero extraído no significa primero aplicado

Dicho esto, el orden de finalización en procesamiento paralelo no queda alineado. Mientras el worker A procesa el trabajo 1, el worker B salta esa fila mediante READPAST y puede confirmar primero el trabajo 2.

Cuando el orden de aplicación tiene sentido —actualizaciones contra el mismo número de pedido, por ejemplo— elija una de las siguientes.

Si no elige ninguna, indique de forma explícita en el diseño que no se garantiza un FIFO global en procesamiento paralelo. El mismo problema surge con MSMQ en cuanto se recibe en paralelo. Lo que importa es no migrar creyendo todavía que «es una cola, así que sale en orden».

5.5. El límite de transacción del worker

Lo que alinea en el lado receptor es la transacción que cubre la extracción, la actualización de los datos de negocio y el registro de finalización. En el pseudocódigo siguiente, las tres operaciones reciben la misma conexión y transacción y se confirman juntas al final.

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
}

El punto clave es que DequeueOne, ApplyBusinessData y MarkDone usan la misma conexión y transacción, y que el Commit final confirma juntas la extracción y la actualización de negocio. Si sustituye esto por un bróker, se pierde esta propiedad de la misma base y hace falta otro diseño de consistencia.

5.6. Recuperación, reintento y limpieza que hay que añadir para producción

Encima del ejemplo mínimo, diseñe las operaciones siguientes.

En los sistemas de negocio de tamaño pequeño y mediano, una tabla más sondeo, o una variante impulsada por notificación, suele bastar. Antes de añadir otro producto de cola, compruebe si esta implementación ya satisface las propiedades y la operación que necesita.

6. Corte: alinear primero el formato, el comportamiento y el lado receptor

Para el corte, alinee primero el formato de mensaje y las pruebas sobre entradas y resultados. Después, elija entre puentear lo antiguo y lo nuevo y vaciar la cola antigua antes de cambiar.

6.1. Decidir un formato de mensaje en el que lo antiguo y lo nuevo puedan coexistir

Haga de JSON el valor predeterminado tras la migración. Lo que no lleva es la serialización basada en BinaryFormatter como BinaryMessageFormatter. La implementación de BinaryFormatter se eliminó del runtime en .NET 9 y tampoco se recomienda por motivos de seguridad.⁸

Eso no significa, sin embargo, que todo formato binario quede fuera. Los formatos cuya especificación se mantiene de forma independiente, como Protocol Buffers y MessagePack, se pueden llevar al sistema nuevo tal cual sin problema. Establezca primero el formateador y el tipo del cuerpo, en el inventario del apartado 3.2.

6.2. Antes de reescribir, fijar entradas y resultados con pruebas

El procesamiento de colas es un área en la que es fácil introducir defectos dependientes del momento. Prepare de antemano pruebas de caracterización que digan «este mensaje de entrada produce este resultado», para poder verificar de forma mecánica que el reemplazo produce el mismo resultado. Véase también «Cómo modificar con seguridad una aplicación de negocio legada sin pruebas — la práctica de las pruebas de caracterización y la refactorización».

6.3. Tratar primero el lado receptor y diseñar el puente en torno a la pérdida y la duplicación

Pasar primero el lado receptor

Primero aprovisione la cola nueva, haga funcionar el lado receptor contra ella y solo entonces cambie el lado emisor.

Insertar un puente pequeño que mueva mensajes del MSMQ antiguo a la cola nueva le ahorra cambiar todos los emisores de una vez. El propio puente puede quedarse en .NET Framework.

Separar el procedimiento de entrega según si se usan transacciones

Pero si se detiene entre extraer de MSMQ y escribir en la cola nueva, obtiene o bien pérdida o bien entrega doble. Diseñe como sigue, según el tipo de cola de origen.

El atributo transaccional de una cola se fija al crearla y no se puede cambiar después. Tenga en cuenta que el procedimiento de recepción transaccional no se puede aplicar sin más a una cola no transaccional.

6.4. Si el puente no compensa, vaciar la cola y cambiar

Si las medidas contra la pérdida y la duplicación en el puente están fuera de proporción con el tamaño del sistema, no fuerce la coexistencia de lo antiguo y lo nuevo; inclínese a vaciar la cola antigua durante una parada planificada y luego cambiar.

Cambiar con mensajes todavía sentados en la cola provoca procesamiento doble y pérdida. Vaciar la cola antes de cambiar es, al final, a menudo la vía más segura y la más rápida: ese es el juicio práctico de este artículo.

7. Resumen

A fecha de julio de 2026, el punto de referencia de este artículo, MSMQ no se ha puesto oficialmente en desuso. Sobrevivir como función del sistema operativo y ser fácil de migrar a .NET son dos cosas distintas. System.Messaging está confinado a .NET Framework, así que la norma es que, si sube la aplicación a .NET, revise la cola al mismo tiempo.¹²³

Si sigue usándolo por el momento, compruebe el periodo de soporte del sistema operativo y ponga en marcha los procedimientos de construcción y recuperación, el monitoreo de colas, un registro de la configuración y una revisión anual de la decisión. El gran riesgo de dejarlo congelado no es solo técnico: es que no quede nadie que pueda tocarlo.

Si migra, inventarie primero las dependencias y los formatos de mensaje. Para el procesamiento asíncrono que actualiza la misma base de negocio, una cola de tabla es la primera opción. La consistencia que aportaban MSMQ más DTC se puede sustituir por una transacción local en esa única base. Considere RabbitMQ o Azure Service Bus cuando hay un requisito que no cubre, como la entrega a varios sistemas o el enrutado.

Encima de eso, compruebe el nivel de aislamiento SQL y las sugerencias, el orden en que se aplican las actualizaciones bajo paralelismo y las medidas contra la pérdida y la duplicación en el puente. Lo que importa es no precipitarse porque «parece que se ha discontinuado», sino entender de qué depende su propio sistema y decidir sobre esa base entre conservarlo y migrar.

Artículos relacionados

• ¿Hasta cuándo seguirán funcionando las aplicaciones VB6? — Estado del soporte del runtime y un camino práctico hacia la migración a .NET
• Lista de verificación previa a la migración de .NET Framework a .NET
• Cómo modificar con seguridad una aplicación de negocio legada sin pruebas — la práctica de las pruebas de caracterización y la refactorización
• Cómo elegir la comunicación entre procesos en Windows — canalizaciones con nombre / TCP / gRPC / memoria compartida / COM: tabla de decisión
• El malentendido de que TCP permite recibir por cada unidad enviada con Send ── diseño de recepción para tratarlo como flujo de bytes
• Cuando hereda un sistema sin código fuente ni documentación — Procedimiento práctico para operarlo y mantenerlo sin detenerlo
• Cómo versionar el esquema de la base de datos de una aplicación empresarial — Migraciones que evitan que «cada cliente tenga una base de datos distinta»

Áreas de consultoría relacionadas

KomuraSoft LLC se encarga de inventarios y planes de migración de configuraciones legacy que incluyen MSMQ, de la migración de .NET Framework a .NET y de la modificación de sistemas de negocio que implican procesamiento de colas.

• Aprovechamiento de activos existentes y soporte de migración
• Modificación y mantenimiento de software Windows existente
• Desarrollo de aplicaciones Windows
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿MSMQ ha sido discontinuado?

No. A fecha de julio de 2026, MSMQ no figura ni en la lista de funciones en desuso de los clientes Windows ni en la lista de «funciones eliminadas o cuyo desarrollo ha finalizado» de Windows Server. Se sigue incluyendo como función opcional en los sistemas operativos actuales. La idea de que «ha sido discontinuado» se ha extendido porque se confunde con la situación del lado de .NET. La biblioteca de clases estándar para manejar MSMQ, System.Messaging, solo existe en .NET Framework y nunca se portó a .NET (Core en adelante). En otras palabras, el estado exacto es: «sigue existiendo como función del sistema operativo, pero no hay una vía oficial de uso desde .NET moderno».

¿Hay alguna forma de usar MSMQ desde .NET 8 o .NET 10?

No existe una API administrada oficial. System.Messaging es una API que llega hasta .NET Framework 4.8.1 y no está incluida en el paquete de compatibilidad de Windows (Microsoft.Windows.Compatibility). Técnicamente es posible llamar a la API nativa Win32 de MSMQ (como MQSendMessage) mediante P/Invoke, pero eso implica crear y mantener usted mismo un contenedor (wrapper) que incluya los formateadores y la integración transaccional. Del lado de la comunidad, el proyecto CoreWCF publica un paquete para el transporte MSMQ (CoreWCF.MSMQ), pero está pensado para hospedar en .NET moderno los servicios WCF a los que se llama a través de una cola (es decir, portar el lado servidor de WCF); no es una API de cola genérica que sustituya a System.Messaging ni una alternativa para el cliente emisor. Además, su implementación depende de un port comunitario de System.Messaging para .NET Framework. Puede servir como opción de validación o para una prórroga provisional. CoreWCF en sí cuenta con una política de soporte oficial de Microsoft, pero eso no significa que el port comunitario de System.Messaging del que depende esta implementación de MSMQ tenga la misma garantía; si va a usarlo como base de un sistema de negocio, debe verificar si la versión que emplea está cubierta por la política de soporte y cómo se trata esa dependencia. En la práctica, lo más sensato es migrar también la cola en el momento en que se actualiza la aplicación a .NET.

¿Qué destino de migración es mejor, RabbitMQ o Azure Service Bus?

Antes de elegir entre esas dos opciones, considere usar una tabla de la base de datos como cola. En la mayoría de los sistemas de negocio de tamaño pequeño o mediano que usan MSMQ, el destino de la cola es un proceso que actualiza la propia base de datos de la empresa. En ese caso, con una cola de tabla se puede confirmar la «extracción del mensaje» y la «actualización de los datos de negocio» dentro de la misma transacción local que los datos de negocio, sustituyendo con un mecanismo más simple la consistencia que antes proporcionaba MSMQ combinado con transacciones distribuidas (DTC). Para los requisitos que una cola de tabla no cubre —por ejemplo, la distribución débilmente acoplada entre varios sistemas o la necesidad de un rendimiento (throughput) alto—, conviene evaluar RabbitMQ si el requisito de instalación local (on-premise) es fuerte, o Azure Service Bus si se puede alojar en la nube. Seguir este orden reduce el riesgo de errores.

¿Es válido decidir dejarlo congelado sobre .NET Framework por el momento?

Sí, de forma condicional. .NET Framework 4.8 recibe soporte como componente de Windows siguiendo el ciclo de vida del sistema operativo, y como MSMQ en sí no está en desuso, se puede prever que «seguirá funcionando». Sin embargo, si opta por dejarlo congelado, haga como mínimo estas cuatro cosas: indique explícitamente en el procedimiento de preparación de equipos (kitting) la activación de la función MSMQ, implemente un monitoreo de la longitud de la cola y del diario (journal), documente el formato de los mensajes y la configuración de conexión, y deje un procedimiento de recuperación previendo el cambio de personal a cargo. El verdadero riesgo de dejarlo congelado no es técnico, sino que «deje de haber alguien que pueda tocarlo».

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.