Simple Injector currently resolves unregistered concrete types by default. Although this is convenient in a number of cases, it can also lead to errors. Because of this, Simple Injector has several Diagnostic warnings that shield the user from making errors when using concrete unregistered types, such as:
Some improvements in v4 will even improve the likelihood that configuration mistakes are spotted.
Still however it is possible for the user to shoot himself in the foot, for instance by accidentally resolving a concrete type (when doing dispatching for instance) instead of the interface. This would prevent Simple Injector from being able to apply decorators.
Perhaps we should disable the creation of unregistered concrete types by default, to prevent these errors and supply a configuration switch that allows the user to re-enable this behaviour, for legacy scenarios:
container.Options.ResolveUnregisteredConcreteTypes = true;
I completely vote for disabling this by default. I shot myself in my foot multiple times because concrete types where autowired.
One scenario that comes to mind is where some concrete service is used in a transient component at one part of the solution, but this same component is scoped or singleton in an other part of the solution.
Although Simple Injector will prevent this other application from running when this happens and the exception message is super clear it is most of the times still a surprise why the container won't verify for this application because in my mind nothing has really changed in this application, while in fact something has changed.
And I think it is just sane practice the configure all parts of the application.
I completely agree with disabling this by default. With option to enable when needed. Never had to use this function because CQRS.