NSB 6.4.3
The exception message is:
No constructors on type ‘NServiceBus.Unicast.MessageHandlerRegistry’ can be found with the constructor finder ‘Autofac.Core.Activators.Reflection.DefaultConstructorFinder’.
IoC configuration:
_endpointConfiguration.UseContainer(
customizations => { customizations.ExistingLifetimeScope(lifetimeScope); });
Do I need to exclicitly register NSB into Autofac a part from the UseContainer clause?
Update: this only happens if I pass an existing lifetimeScope. If I don’t do it, it works fine (but obviously there is nothing registered so it can’t resolve the handlers’ dependencies).
Hi Francesc
Are you perhaps using any Modules with your existing Autofac container?
I don’t think we use any moduke, because we use a custom solution to do
something similar to modules as we have a wrapper on top of autofac.
The main problem I had initially using our system with NSB is that with
Autofac you have to build the container and then you cannot register
dependencies any more. But with NSB you expect a built container and then
you have to register more dependencies. Not sure if this can also cause an
issue.
I can’t seem to reproduce this behavior.
I started with the Service Fabric routing sample, and added Autofac as the container. Created a new empty container and then specified that container as the existing lifetime and my endpoints started fine.
Is there any chance you can eliminate most of the sensitive code and host a sample somewhere that I can try?
Yes, I already created a repro and sent it to Mauro. I will send it to you too privately.
Good news, I found the problem!
In the sample that you sent through, you create an Autofac ContainerBuilder, and then immediately register an object source of type AnyConcreteTypeNotAlreadyRegisteredSource. This causes problems with the NServiceBus.Autofac.AutofacObjectBuilder class:
When the AutofacObjectBuilder class is used, it registers all the internal types that NServiceBus needs. It does this by registering the concrete types, and then internally registering all the interfaces that that concrete type implements. Before it does this though, it checks if that concrete type has already been registered or not. If it has been registered, it skips.
By calling AnyConcreteTypeNotAlreadyRegisteredSource, the “is this type already registered” check will always return true, which means the internal types aren’t being registered correctly.
The quick fix is to remove the use of AnyConcreteTypeNotAlreadyRegisteredSource and to rather register the types your application uses explicitly.
Excellent! I’ve managed to refactor the code to remove that object source from the container used by NSB (we still need it for our existing code, but as far as I can tell, the container used by NSB endpoints can/should be different than the one used by the other pipelines (web api requests and remoting stateless services calls mainly).
In short, the issue is resolved.
Thanks!
There is an #if in program.cs which switches from working to failing solution. We need to use the “failing” way because all our dependencies are configured that way.
In case somebody else finds the same issue, I’ve solved it by telling the object source to ignore classes within NServiceBus namespace:
Builder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource(t=>t.Namespace?.StartsWith(“NServiceBus”)!=true));