Allow disabling resolving concrete types

[dotnetjunkie]

TLDR;

This issue introduces an Container.Options.ResolveUnregisteredConcreteTypes configuration flag that allows disabling resolving unregistered concrete types:

var container = new Container();
container.Options.ResolveUnregisteredConcreteTypes = false;

This feature was added to Simple Injector v4.5. In Simple Injector v4.x it defaults to true, which is the pre-v4.5 behavior, which means Simple Injector will try to resolve concrete types on your behalf, even in the absence of a registration for that concrete type.

Simple Injector v5.0 will change the default to false. You are, however, advised to change the setting to false directly while working with Simple Injector v4.x. This prevents surprises when migrating to v5.x.

The rest of this issue describes the long discussion about the design and behavior of this feature.

---

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:

• Short Circuited Dependencies warning
• Ambiguous lifestyles warning

Some improvements in v4 will even improve the likelihood that configuration mistakes are spotted.

Still, however, it is possible for users to shoot themselves 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 behavior, for legacy scenarios:

container.Options.ResolveUnregisteredConcreteTypes = true;

Let's discuss.

[TheBigRic]

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.

[trailmax]

I completely agree with disabling this by default. With option to enable when needed. Never had to use this function because CQRS.

[dotnetjunkie]

I'm really interested to see some examples from developers who are actually currently depending on this behavior.

[alexfoxgill]

Perhaps concrete types could be resolvable if they implement no interfaces? I have in the past used simple 'record' types for providing strongly-typed access to config settings, for example

[dotnetjunkie]

@alexfoxgrill, but wouldn't that require those records to be registered as singleton?

[alexfoxgill]

I don't see how the lifestyle is impacted by this..? You could just as easily have transient instances if you wanted?

[dotnetjunkie]

When you have objects that provide strongly typed access to configuration values, these configuration values should typically be loaded at app startup to ensure the application fails fast in case of a misconfiguration. In case config values are read once at startup, it means that these strongly typed wrappers just wrap the values and are created at startup as well. This means they will be singletons as well.

What you are describing seems an object that contains behavior and forwards the request to something like ConfigurationManager.AppSettings which is sub optional.

The case where this does make a lot of sense is when the comfig values are volatile and can change during the lifetime of the application.

[dotnetjunkie]

I think there are different options here when it comes to resolving unregistered concrete types:

• Simple Injector can try to resolve all unregistered concrete types (current v3 behavior)
• It can resolve unregistered concrete types only if they are a dependency of some other type. The rational behind this is that root types should always be registered, since omiting them make the Diagnostic Services blind, while dependencies are already analyzed by the container and the improvements in the Diagnostic Services of v4 should already find any misconfigurations of unregistered concrete types that are dependencies. To me, unregistered root types will be the biggest problem (as long as users actually call Verify() ofcourse).
• It can resolve unregistered concrete types only if it implements no interfaces, as @alexfoxgill suggests.
• Some other criteria?
• A combination of one of the previous three.
• None. No unregistered concrete type should be resolved.

The dilemma is here that although we want to improve Simple Injector, we also want to prevent introducing breaking changes that will impact and confuse too many users, and potentionally cost a lot of effort to fix, while they might have a valid use case for this.

I'm currently thinking about making the "don't resolve unregistere concrete root types" the default for v4 (although that allone could be quite a breaking change already), where the user might be able to switch to "Resolve All" and "Resolve None" using the Container.Options.

[dotnetjunkie]

After building a proof of concept, a massive amount of (218) tests broke. Main reason for this is that a lot of tests depend on the behavior to be able to resolve unregistered concrete types. But also some of the current code samples in the documentation depend on this behavior (like the interception extensions).

This makes me realize that, although, this change might be a noble one, it might impact more users than I first envisions and it is quite some work to get this feature in correctly.

I am, therefore, going to postpone adding this configuration switch till after v4, and if the default behavior (which is to resolve all unregistered concrete types) is changed, this will be done in the following major release, v5.

Thanks for everyone responding.

[davidroth]

@dotnetjunkie An example which comes to my mind where this feature causes confusion is when using Entity Framework. If I don't want to register my custom DbContext via the DbContext type this can lead to stupid mistakes.

Say for example you have a context named MyCustomContext and you did not register it as DbContext because you you want to explicitly inject MyCustomContext:

// Injects MyCustomContext => everything ok
public MyClass(MyCustomContext ctx) { }

public void SampleMethod() => ctx.Set<MyEntity>(); // ok

However, in another class, you accidentally used DbContext instead of MyCustomContext

// Injects DbContext which does not makes sense and fails later on
public MyClass2(DbContext ctx) { }

// fails because DbContext has no registrations
public void SampleMethod() => ctx.Set<MyEntity>(); 

Of course, you can easily fix this by registering DbContext as MyCustomContext via the registration api:

container.Register<DbContext, MyCustomContext>()

but this only works as long as there is a single DbContext. If you have multiple DbContexts this will fail.

=> I`d prefer to disable resolving unregistered concrete types per default. A switch to enable it would make sense though.