Can't register generic handlers in latest version

[rbasniak]

Hi,

I have some request/handlers like this:

public class CreateScaffoldingResourceOn<TRelation, TParent>
    where TParent : BaseEntity
{
    public class Request : IRequest<CommandResponse>
    {
    }

    public class Handler : IRequestHandler<Request, CommandResponse>
    {
    }
}

The AddMediatR method wasn't able to identify these handlers so I used to register them manually:

services.AddScoped<IRequestHandler<CreateScaffoldingResourceOn<T1, T2, T3>.Request, CommandResponse>, CreateScaffoldingResourceOn<T1, T2, T3>.Handler>();

This worked fine until I updated to 12.3.0. Now I am getting the following exception in the AddMediatR method:

System.ArgumentException: 'The number of generic arguments provided doesn't equal the arity of the generic type definition. (Parameter 'instantiation')'

If I comment these handlers from my assembly, then my application starts again, so the problem is definitely related to registration changes in the latest version.

Is this a bug or an intended change? If so, what would be the suggestion to keep using the latest version?

[zachpainter77]

Yes, this is a bug with the new version. I am working on a fix and have just about got it.. However need some input from others in regards to some limits to put on these features.

The issues arise from the new updated support of generic handlers to not support generic requests with more than one type parameter.

The issue is fixed in my local version however this also let's users define too many types which could cause mediatR to hang in service registration as you could understand if there were too many type parameters each with it's own number of types that can close that type parameter.

I'm trying to come up with a solution that will register handlers like your's above and will not let the user essentially soft lock their app when being too vague with parameters. For example, SomeRequestType<T1, T2, T3, etc.. TN> with no constraints makes it very complex to compute every single possible concrete combination of SomeRequestTypeHandler<SomeRequestType<T1, T2, T3, etc.. TN>>.

In the meantime a workaround is to:

1. revert back to previous version
   or
2. update your add mediator call configuration to provide a type evaluator that will tell mediator to skip trying to register your generic request handlers. (this will not affect your manual registrations)

builder.Services.AddMediatR(config => {
    config.TypeEvaluator = x => !x.ContainsGenericParameters;
    config.RegisterServicesFromAssemblies(assemblies);
});

by setting up mediatR this way you tell it to only try to register handler types that do not contain generic type parameters. (The default behavior of previous versions)

[rbasniak]

Thanks for the reply, for me, the workaround is enough for my needs, so I am closing this issue.

[sorbonad]

Hello, the improvement / fix mentioned is something that is going to be released soon or it will take time? thanks

[zachpainter77]

Hello @sorbonad There is an active pull request that fixes the issue.. It might take some time to get merged. Until then, you can implement this workaround:

builder.Services.AddMediatR(config => {
    //add this line to filter out handlers that contain generic parameters. 
    //This will effectively turn off the newly added feature.
    config.TypeEvaluator = x => !x.ContainsGenericParameters;
    config.RegisterServicesFromAssemblies(assemblies);
});

Or roll back MediatR to the previous version.

[sorbonad]

Alright, thank you @zachpainter77