jbogard / MediatR

Simple, unambitious mediator implementation in .NET
Apache License 2.0
10.84k stars 1.15k forks source link

Can't register generic handlers in latest version #1043

Closed rbasniak closed 2 weeks ago

rbasniak commented 3 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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