Closed dotnetjunkie closed 3 years ago
feature-863 branch created.
After doing some more research, I found that the unit tests do a good job in explaining what can happen when GetRegistration
does not lock the container:
Whenever a not-explicitly made registration can be returned using unregistered type resolution, the container needs to be locked, changing the container might invalidate the registration. For instance, adding unregistered type resolution events later, might cause a different registration to be returned when
GetRegistration
is called again.
This means that the locking behavior can't be fully removed. Still, I feel that it's okay to loosen the behavior and only lock when the registration is made implicitly.
As described in #862, Simple Injector is very strict in locking the
Container
when callingGetRegistration
. The current behavior is to "lock the container in all cases except when an explicitly made registration can be returned." This means that in the following cases, the container will lock:DependencyMetadata<T>
ResolveUnregisteredConcreteTypes
is set.There are cases where a call to
GetRegistration
should certainly cause the container to be locked, such as when the underlying code triggers a call toContainer.GetInstance
,GetService
, orGetAllInstances
, orBuildExpression
. For instance, an unregistered type resolution event might do this.But for
GetRegistration
itself, it could itself leave the container unlocked.Not locking the container has become extra important in v5, because locking the container now, by default, triggers verification. This means that a call to
GetRegistration
causes the verification, which can be confusing. It also disallows the use ofGetRegistration
to make decide what and how to register.Tasks:
LockContainer
from theGetRegistration
method.GetRegistration
method to see if they are up to date, and if not update them.