You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The private Container.AddContainerRegistrations methods registers the Scope type using the specially crafted ScopedScopeLifestyle, but there are some quirks with that approach:
The ScopedScopeLifestyle.GetCurrentScopeCore method never returns null, but instead throws an exception. This complicates the code, because in AddContainerRegistrations it seems as if the registered delegate can actually return null (this actually came up when working on Implement C# 8 non-nullable support #649).
When there is no active scope, ScopedScopeLifestyle throws a simple "There is no active scope" message, which is too minimalistic and, therefore, confusing to the user as it does not explain what scope we are talking about and how to fix the problem.
ScopedScopeLifestyle.GetCurrentScopeCore calls container.GetVerificationOrResolveScopeForCurrentThread, but that will always return null, since ScopedLifestyle.GetCurrentScope always returns that value before calling into GetCurrentScopeCore. This statement was incorrect as a created "current scope provider" (created by calling ScopedLifestyle.CreateCurrentScopeProvider) bypasses GetCurrentScope and directly calls the private GetScopeFromDefaultScopedLifestyle. Removing this check, therefore, causes an incorrect exception during verification.
It might be better to completely remove ScopedScopeLifestyle and the indirection it causes, but in that case a different way must be found to allow registering Scope with a scoped lifestyle, as this method is called early in the pipeline (Container ctor), at a stage that DefaultScopedLifestyle is not set.
The text was updated successfully, but these errors were encountered:
After more thorough investigation, the ScopedScopeLifestyle allows errors to be reported in a way that would otherwise be hard to achieve. For instance by throwing the right messages during verification. Because of that, only the thrown message texts will be improved in this fix.
The private
Container.AddContainerRegistrations
methods registers theScope
type using the specially craftedScopedScopeLifestyle
, but there are some quirks with that approach:ScopedScopeLifestyle.GetCurrentScopeCore
method never returnsnull
, but instead throws an exception. This complicates the code, because inAddContainerRegistrations
it seems as if the registered delegate can actually return null (this actually came up when working on Implement C# 8 non-nullable support #649).ScopedScopeLifestyle
throws a simple "There is no active scope" message, which is too minimalistic and, therefore, confusing to the user as it does not explain what scope we are talking about and how to fix the problem.This statement was incorrect as a created "current scope provider" (created by callingScopedScopeLifestyle.GetCurrentScopeCore
callscontainer.GetVerificationOrResolveScopeForCurrentThread
, but that will always returnnull
, sinceScopedLifestyle.GetCurrentScope
always returns that value before calling intoGetCurrentScopeCore
.ScopedLifestyle.CreateCurrentScopeProvider
) bypassesGetCurrentScope
and directly calls the privateGetScopeFromDefaultScopedLifestyle
. Removing this check, therefore, causes an incorrect exception during verification.It might be better to completely remove
ScopedScopeLifestyle
and the indirection it causes, but in that case a different way must be found to allow registeringScope
with a scoped lifestyle, as this method is called early in the pipeline (Container
ctor), at a stage thatDefaultScopedLifestyle
is not set.The text was updated successfully, but these errors were encountered: