MassTransit v8

[phatboyg]

MassTransit v8 will be the first major release since the availability of .NET 6. MassTransit v8 works a significant portion of the underlying components into a more manageable solution structure. Focused on the developer experience, while maintaining compatibility with previous versions, this release brings together the entire MassTransit stack.

Consolidation

Automatonymous, Green Pipes, and NewId have been integrated into a single MassTransit solution. This brings the core functionality of MassTransit into a single namespace. This makes it easier to find the right interface, extension method, or component needed. Many new MassTransit developers struggle with missing using statements and with this change that should no longer be an issue. For the most part the entire developer surface area exists within the MassTransit namespace, requiring only:

using MassTransit;

Configuration

While the core MassTransit components can be used on their own, without a container, the vast majority of users configure MassTransit using the AddMassTransit extension method. And without prompting, they most commonly don't see to also configure the hosted service using AddMassTransitHostedService. With v8, Microsoft.Extensions.Hosting.Abstractions is now included, and the hosted service is registered by default. This means no more separate call to AddMassTransitHostedService and no dependency on MassTransit.AspNetCore.

The hosted service can also be configured using the standard Microsoft configuration extensions. For instance, all of the following options are optional, but can be configured.

services.ConfigureOptions<MassTransitHostOptions>(options =>
{
    options.WaitUntilStarted = true;
    options.StartTimeout = TimeSpan.FromSeconds(30);
    options.StopTimeout = TimeSpan.FromMinutes(1);
});

Containers

MassTransit is now using Microsoft.Extensions.DependencyInjection.Abstractions as the standard dependency injection mechanism. This means that all configuration (such as AddMassTransit, AddMediator) is built against IServiceCollection.

MassTransit registrations (consumers, sagas, activities, futures, as well as endpoints) are now managed completely inside the container, allowing developers to create their own discovery/configuration constructs while still being able to use the AddMassTransit/UsingXxxx syntax.

Third Party Containers

Support for other containers, such as AutoFac, Simple Injector, StructureMap, and Castle Windsor will no longer be provided. For those containers, if they support configuration via IServiceCollection and provide an IServiceProvider implementation, they can be used with MassTransit (exactly the same as if they were being used with ASP.NET Core).

For example, Autofac provides an integration package resulting in code similar to what is shown below:

var collection = new ServiceCollection()
    .AddMassTransit(x =>
    {
        x.AddConsumer<SubmitOrderConsumer>();

        x.UsingRabbitMq((context, cfg) => cfg.ConfigureEndpoints(context));
    });

var factory = new AutofacServiceProviderFactory();
var container = factory.CreateBuilder(collection);

container.RegisterType<ConsumerDependency>().As<IConsumerDependency>().InstancePerLifetimeScope();

var provider = factory.CreateServiceProvider(container);

In this example, some components are registered via Autofac (the consumer dependency), and the MassTransit configuration is used to add consumers, configure the bus, etc.

Unit Testing

With the container integration mentioned above, it's important to refresh how unit tests are created to simplify the creation of tests using the container. As such, an initial example of a new unit test is shown below. The final syntax is still being tweaked with the goal to make it easy to test consumers, sagas, state machines (including custom state machine activities), and routing slip activities.

[Test]
public async Task The_consumer_should_respond_to_the_request()
{
    await using var provider = new ServiceCollection()
        .AddMassTransitTestHarness(x =>
        {
            x.AddConsumer<SubmitOrderConsumer>();
        })
        .BuildServiceProvider(true);

    var harness = provider.GetRequiredService<ITestHarness>();

    await harness.Start();

    var client = harness.GetRequestClient<SubmitOrder>();

    await client.GetResponse<OrderSubmitted>(new
    {
        OrderId = InVar.Id,
        OrderNumber = "123"
    });

    Assert.IsTrue(await harness.Sent.Any<OrderSubmitted>());

    Assert.IsTrue(await harness.Consumed.Any<SubmitOrder>());
}

This test uses the request client (which is now configured by default using a generic request client) to get a response from the consumer.

To be continued...

[phatboyg]

Also, will include the serialization rewrite: #2727

[cd21h]

Please keep NewId as a separate package, I'm using it for projects without MassTransit

[phatboyg]

It still a separate package, and won't be updated. But NewId is integrated into MassTransit.Abstractions and is no longer referenced by MassTransit.

[cd21h]

Hi Chris.

Regarding third-party containers, e.g. Autofac: it supports tagged lifetime scopes and nested containers (registration overrides). First one might not be a big issue, but nested containers could be a problem. Could you suggest how to implement this using MS DI in MT8?

Thanks

[phatboyg]

Unfortunately, you're on your own in that regard. I haven't had any time to look at how developers have migrated from Autofac to MS DI in those scenarios.

[phatboyg]

I imagine that it would require something similar to the various extensions for ASP.NET to allow nested containers as root, etc.

https://autofac.readthedocs.io/en/latest/integration/aspnetcore.html#multitenant-support

[rsandsand]

Is there a planned released date for MT8?

[phatboyg]

A previously announced sometime in Q1. So within the next six weeks.

[SrdjanPaunovic]

Hi @phatboyg,
What happened with AddScopedFilter<TContext, TFilterContext, T> in DependencyInjectionFilterContextScopeProvider class?
I can't find this extension or replacement for this. What I can use to define scoped filter for specific consumers with specific messages?

[phatboyg]

The only methods currently available are for the various filters supported:

UseConsumeFilter
UseSendFilter
UsePublishFilter
UseExecuteActivityFilter
UseCompensateActivityFilter

[SrdjanPaunovic]

I have something similar to this:

`config.Consumer(context, (consumerConfig) =>

    {
        consumerConfig.ConsumerMessage<TMessage>(p =>
        {
         p.AddScopedFilter<ConsumerConsumeContext<TConsumer, TMessage>, ConsumeContext<TMessage>, TMessage>(typeof(MyFilter<>), context)
       });
    });`

I there a way I can register this generic filter that can work with DI like before?

[phatboyg]

I don't believe so, the change was made in v8 for all scoped filters to execute prior to resolving the consumer from the container. This ensures that any security, authorization, tenancy, etc. filters are executed prior to the consumer resolution.

[SrdjanPaunovic]

I write extension that works for me.

public static void AddScopedFilter<TConsumer, TMessage>(this IPipeConfigurator<ConsumerConsumeContext<TConsumer, TMessage>> configurator, Type scopedType,
            IServiceProvider provider)
            where TConsumer : class, IConsumer<TMessage>
            where TMessage : class
    {
        if (!scopedType.IsGenericType || !scopedType.IsGenericTypeDefinition)
            throw new ArgumentException("The scoped filter must be a generic type definition", nameof(scopedType));

        var filterType = scopedType.MakeGenericType(typeof(TConsumer), typeof(TMessage));

        if (!filterType.HasInterface(typeof(IFilter<ConsumerConsumeContext<TConsumer, TMessage>>)))
            throw new ArgumentException($"The scoped filter must implement {TypeMetadataCache<IFilter<ConsumeContext<TMessage>>>.ShortName} ", nameof(scopedType));

        Type scopeProviderType = typeof(FilterScopeProvider<,>).MakeGenericType(filterType, typeof(ConsumerConsumeContext<TConsumer, TMessage>));

        IFilterScopeProvider<ConsumerConsumeContext<TConsumer, TMessage>>? scopeProvider = (IFilterScopeProvider<ConsumerConsumeContext<TConsumer, TMessage>>?)Activator.CreateInstance(scopeProviderType, provider);

        if (scopeProvider is null)
        {
            throw new Exception("Failed to create scopeProvider instance.");
        }

        ScopedFilter<ConsumerConsumeContext<TConsumer, TMessage>> filter = new(scopeProvider);
        FilterPipeSpecification<ConsumerConsumeContext<TConsumer, TMessage>> specification = new(filter);

        configurator.AddPipeSpecification(specification);
    }

Can you check if this makes sense to you?

[phatboyg]

If it compiles and works for you, there you go.

[marinasundstrom]

I have updated to Version 8. Removed .AspNetCore project.

So Generic Request Client is now automatically registered?

[phatboyg]

That's correct.

[marinasundstrom]

Great! Simplifies a lot!

I really like Abstractions. Now I can easily switch out my lazy HTTP calls for MassTransit in my Application layer(s) when doing cross-service communication. Since IRequestClient is accessible without the entire MassTransit being referenced.