Using steeltoe connectors with EasyNetQ is awkward.

[macsux]

Problem

EasyNetQ is a popular package that provides high level abstrations for working with RabbitMQ. The way it wants to be configured is via its own configuration class that expects to be provided individual connection string elements of RabbitMQ (host, port, credentials, SSL settings, etc). Example:

builder.Services.RegisterEasyNetQ(svc =>
    {
        return new ConnectionConfiguration
        {
            Hosts = new List<HostConfiguration> { host },
            UserName = username,
            Password = password
        };
    });

Currently, connectors do not provide easy way to access individual elements needed to configure it. The closest is the ability to inject RabbitMQOptions that only exposes string ConnectionString property, requiring one to parse it manually.

Proposed solution

Register both IConnection and IConnectionFactory from RabbitMQ. If IConnectionFactory is available, it can be cast back to ConnectionFactory and all the elements copied over. Alternatively (or in addition), expose make RabbitMQConnectionStringBuilder public and expose individual well-known elements of connection string as strongly type properties.

[bart-vmware]

Thanks, it would be nice to have built-in support for EasyNetQ, or at least have a sample demonstrating how it can be used.

It shouldn't be hard to use already though, because the format of the connection string is just a URI (see https://github.com/SteeltoeOSS/Samples/blob/latest/Connectors/src/RabbitMQ/Program.cs). So by parsing it into System.Uri from options, its host/port/username/password, etc can be obtained to set up ConnectionConfiguration.

There's also an overload that takes a connection string. Their IServiceResolver and IServiceRegister look similar to IServiceCollection and IServiceProvider, so maybe they can be used.

[macsux]

Here's a sample app that uses RabbitMQ: https://github.com/macsux/pcf-ers-dotnetcore-demo/blob/9f21a82663be0a5d11b971cfb6e57cf2fe775698/src/CloudPlatformDemo/Program.cs#L169

As far as connection string overload, it requires knowledge of it's value during registration time. It's not available yet as it will only be made available as part of IOptions<RabbitMQOptions> after container is built.

[bart-vmware]

I tried this from a unit test, seems to work:

builder.Services.RegisterEasyNetQ(serviceResolver =>
{
    var optionsMonitor = serviceResolver.Resolve<IOptionsMonitor<RabbitMQOptions>>();
    RabbitMQOptions options = optionsMonitor.Get(null);

    var parser = serviceResolver.Resolve<IConnectionStringParser>();
    return parser.Parse(options.ConnectionString);
});

await using WebApplication app = builder.Build();

var bus = app.Services.GetRequiredService<IBus>();