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
Currently, Simple Injector completely skips verification of open-generic registrations that have no (registered) (closed or non-generic) consumers. The reason for this is 'omission' is that in order to verify a type, Simple Injector must first be able to construct an expression tree, after which it can compile and execute that expression tree. This, however, requires a closed-generic types; open-generic types can't be created.
It is impossible for Simple Injector to reliably deduct a possible closed-generic version of that type that could be used for verification, because of the following reasons:
It might cause the construction of a closed version that the user never had the intention of creating; causing the creation of closed-generic dependencies that weren't intended to be created, possibly multiple layers deep.
A type might have a constructor or static constructor that verifies the correctness of the type arguments in a way that can't be solved using generic type constraints (for instance whether the used generic argument types are marked with a [Permission] attribute of some sort).
Even if one specific closed-generic version could be picked for verification, it doesn't mean that all closed-generic versions could be composed.
Brute forcing all possibilities, however, could possibly take hours or even days, and would blow up the memory use of the application.
Although its impossible to invoke the root component's static constructor and instance constructor, it might still be possible to do a partial analysis on the type and its dependencies, because it is still possible to:
check for captive dependencies
missing dependencies
We might, though, be forced to skip open-generic dependencies, this is still better than skipping verification altogether.
Obvious downside from an implementer's perspective is the added complexity, because it will require quite some new code to be written; the current verification depends on the creation of InstanceProducer instances, but that's completely out of the picture (because it requires to have closed-generic types).
Another downside of adding such feature is the false sense of security we might give the user, who might think that open-generic types are verified in the same way as other dependencies are, while we can only do a limited check.
The text was updated successfully, but these errors were encountered:
Currently, Simple Injector completely skips verification of open-generic registrations that have no (registered) (closed or non-generic) consumers. The reason for this is 'omission' is that in order to verify a type, Simple Injector must first be able to construct an expression tree, after which it can compile and execute that expression tree. This, however, requires a closed-generic types; open-generic types can't be created.
It is impossible for Simple Injector to reliably deduct a possible closed-generic version of that type that could be used for verification, because of the following reasons:
[Permission]
attribute of some sort).Although its impossible to invoke the root component's static constructor and instance constructor, it might still be possible to do a partial analysis on the type and its dependencies, because it is still possible to:
We might, though, be forced to skip open-generic dependencies, this is still better than skipping verification altogether.
Obvious downside from an implementer's perspective is the added complexity, because it will require quite some new code to be written; the current verification depends on the creation of
InstanceProducer
instances, but that's completely out of the picture (because it requires to have closed-generic types).Another downside of adding such feature is the false sense of security we might give the user, who might think that open-generic types are verified in the same way as other dependencies are, while we can only do a limited check.
The text was updated successfully, but these errors were encountered: