Is it possible to register Producer or Consumer at runtime?

[manish-doshi]

As per the sample code, it is only possible to register Producers and Consumers only at the DI time. Is it possible to register Producers and Consumers at runtime.

Also, is it possible for non-DI object to register itself as a consumer at runtime?

[zarusz]

Hello,

At the moment, it is not possible to add additional consumers or producers at runtime. The current implementation performs certain optimizations and initializations during application startup, which would complicate support for dynamic configuration. Additionally, integrating this capability would present further challenges with plugins like Outbox.

So far, dynamic reconfiguration hasn't been a required use case, which is why it hasn't been implemented.

That said, we’re open to considering this feature. However, it would involve changes to the core logic as well as all existing transport implementations.

Could you please share more details about your use case and requirements? This would help us better understand the need and evaluate potential solutions.

[manish-doshi]

Consider a scenario where I have a background thread/task that needs to produce or consume a message. This task/thread is not spawned using DI. How can this be done?

[manish-doshi]

I also get an error while using it in DI. Please review another discussion and let me know how to fix that issue.
#405

[zarusz]

@manish-doshi — trying to make sure I understand your use case correctly.

Are you looking to submit some async work (via a bus Send or Publish request), have it processed in the background, and then have it notify or return when completed?

You also mentioned that the background work isn’t being created via dependency injection (DI), so I assume the producer already knows what needs to be done?

Here are a few ideas based on that understanding:

---

1. Auto-register producers and handlers using .AutoDeclareFromAssemblyContaining<>

When configuring the in-memory message bus, you can use AutoDeclareFromAssemblyContaining<>() to scan and register producer and handler types from an assembly. This works similarly to how MediatR auto-discovers handlers.

Check out the ValidatingWebApi sample, which uses CQRS and auto-discovers command and query handlers at startup.

1a. If the background work doesn't need to return a result (i.e. fire-and-forget), you can publish it using bus.Publish(...) and configure the memory provider with EnableBlockingPublish = false.

---

2. Use a generic background command pattern

Another option is to define a generic message structure (e.g., wrapping a Func<Task>) and a single consumer that executes the provided work. Example:

builder.Services.AddSlimMessageBus(mbb => mbb
    .WithProviderMemory(cfg => cfg.EnableBlockingPublish = false)
    .AutoDeclareFrom(Assembly.GetExecutingAssembly())
);

class MyBackgroundCommand
{
    public Func<Task> TheWorkFactory { get; set; }
}

class MyBackgroundCommandConsumer : IConsumer<MyBackgroundCommand>
{
    public async Task OnHandle(MyBackgroundCommand message, CancellationToken token)
    {
        await message.TheWorkFactory();
    }
}

// Usage
await bus.Publish(new MyBackgroundCommand
{
    TheWorkFactory = async () =>
    {
        // Your async work here
    }
});

---

3. Variants of the above

You could also build on #2 by letting the consumer construct or manage the actual work to be performed, depending on what level of control and abstraction you need.

---

I’m working off a few assumptions here, so feel free to clarify your exact requirements and we can refine the approach further.

[manish-doshi]

Thanks @zarusz for your reply. I will look into it and get back to you when I start building more stuff using your suggestions.