You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you have no localhost RabbitMQ running, I figured out to use the following setup:
(to repro: just create a dotnetcore2.0 console app and (only) nuget EzBus.RabbitMQ in it)
However, the config delegate never gets called. Because the DI container resolves IBusConfig already as part of the Bus.Configure() call (which internally calls GetTransport() which finds as class to use the RabbitMQTransport class that contains an IConfig param in the ctor...). A little later that same config is used to create a connection which obviously fails because it uses the hardcoded defaults (localhost, guest user, etc.) that do not apply. All of this happens even before the call to UseRabbitMQ, so in reality you never get a chance to modify the config.
Is this a design bug, or am I doing something wrong? It looks like the DiceRoller Client from the samples also uses a non-standard config 'BROKR', so it can also be 'work in progress'? Normally I try to find some time to look into it myself some more, but it looks like this one needs diving in too deep for now.
Thanks, library looks great otherwise!
Reinhard
The text was updated successfully, but these errors were encountered:
Hello,
If you have no localhost RabbitMQ running, I figured out to use the following setup:
(to repro: just create a dotnetcore2.0 console app and (only) nuget EzBus.RabbitMQ in it)
However, the config delegate never gets called. Because the DI container resolves IBusConfig already as part of the Bus.Configure() call (which internally calls GetTransport() which finds as class to use the RabbitMQTransport class that contains an IConfig param in the ctor...). A little later that same config is used to create a connection which obviously fails because it uses the hardcoded defaults (localhost, guest user, etc.) that do not apply. All of this happens even before the call to UseRabbitMQ, so in reality you never get a chance to modify the config.
Is this a design bug, or am I doing something wrong? It looks like the DiceRoller Client from the samples also uses a non-standard config 'BROKR', so it can also be 'work in progress'? Normally I try to find some time to look into it myself some more, but it looks like this one needs diving in too deep for now.
Thanks, library looks great otherwise!
Reinhard
The text was updated successfully, but these errors were encountered: