Decorator without any registrations on decorated type causes MissingTypeRegistrationException

Hello!

I am using the following code:

services.Scan(a =>
{
    a.FromAssembliesOf(typeof(DataLayerServiceProviderExtensions))
        .AddClasses(p => p.AssignableTo(typeof(IQueryHandler<,>)))
        .AsClosedTypeOf(typeof(IQueryHandler<,>))
        .WithTransientLifetime();
});

services.Decorate(typeof(IQueryHandler<,>), typeof(LoggingQueryHandlerDecorator<,>));

This registers all IQueryHandlers in my project and decorates each of them with a decorator.

---

I am currently setting up a project. It does not yet contain any queryhandlers, but I of course would like to already set up all DI registrations, so when I do add queryhandlers things work just fine. Also, if I have a project “template” that does not necessary contain queryhandlers by default but does support them, having the code above in the project would be a great benefit instead of having to add it later.

I would expect that if the project has no queryhandlers registered, no decorations would be applied. Things would work just fine. But this is not the case.

Right now, when I run this code the following exception is thrown on the line of the decorator.

Scrutor.MissingTypeRegistrationException: 'Could not find any registered services for type IQueryHandler<TQuery, TResult>'.'

Perhaps this should not be an exception? Thanks?

[sander1095]

Hm, I guess my original issue is fixed if I use TryDecorate. 😃 No need to discuss this further, thank you for your help, I will close this issue!

[khellang]

My code example that scans for IQueryHandlers doesnt throw even though there are no registrations to be found. Why is this different?

Because Decorate relies on services being present in order to do its job. Scan doesn’t in the same way.

I get that it would be more consistent to (not) throw in both cases. After all, having a scan result in no registrations could very well indicate a developer error. But changing that behavior now would be a breaking change.

If using TryDecorate works for you, I’ll consider this issue “solved”, but we can leave it open as a reminder to split Scan into a non-throwing TryScan alterative 😄

I feel like not throwing when none are found is a good idea, but you are the owner of the codebase and I only have my own usage to draw from, so I am unsure if my usage reflects all the usecases this library covers.

I feel the opposite. No types probably means you screwed up something. And I’d like to find that out as soon as possible 😅