Is there a way to send message to an older version of rebus

[talisker77]

Older versions of rebus had one table for input queue and a recipient as column. Never versjon is one table per queue if stored in SqlServer. With net6 and using rebus 7.X, I need to publish to a rebus using sqlserver with version 4.X. I have no way to update the older version.

With version 7.X is it possible to send a message to a subscriber using an older version without getting this message:

I want to publish a message to a predefined table, where input queue is specified as name in this predefined table.

Thanks for any guideance.

//using current setup in net6:
 using var activator = new BuiltinHandlerActivator();
    var bus = Configure.With(activator)
    .Logging(l => l.Serilog())
    .Transport(t => t.UseSqlServer(
        new SqlServerTransportOptions(
                builder.Configuration.GetValue<string>("ConnectionStrings:Rebus")
                , enlistInAmbientTransaction: true
            )
            , builder.Configuration.GetValue<string>("Rebus:EkspederingQueue")

        ))
    .Subscriptions(s => s.StoreInSqlServer(
        builder.Configuration.GetValue<string>("ConnectionStrings:Rebus"),
        "eks_BusSubscriptions", isCentralized: true
    ))
    //.Routing(conf => { })
    //.Serialization(s => s.UseNewtonsoftJson(JsonInteroperabilityMode.PureJson))
    .Start()
    ;

[talisker77]

Seems like it is possible to run v4.x with rebus.sqlserver v4.0 within dotnet 6. This solves the immediate issue. Would be good, if there would be possible to use latest version and still send/publish messages using sqlserver to v4.x

[mookid8000]

While Rebus.SqlServer DID make a pretty drastic change at some point from using one single messages table to the more scalable "table-per-queue" layout, it should be possible with some carefully written

insert into [NewTable] select [Id], [Headers], [Body], .... from [Messages] where [Recipient] = 'NewTable';

or something like that to copy messages from the old table into the new one.

While this might not be ideal, it should be possible to leverage this approach when transitioning from the older layout to the new.

Also, please keep in mind that the SQL transport is not a real message broker. It has a bunch of limitations that real queueing systems do not have, so please only use it for small things. 🙂