-
-
Notifications
You must be signed in to change notification settings - Fork 12
No way to remove type from ConstructorResolverCache #133
Comments
Thanks for making a issue about this and providing some code to reproduce this. You are correct that Singularity uses a global cache here https://github.com/Barsonax/Singularity/blob/master/src/Singularity/Settings/ConstructorResolvers.cs due to static being used. In most cases this is fine except in yours. Contemplating whether to remove the static though and move to a instance based approach as that would make it clearer that something is being cached and in what context. You can however instantiate the resolvers yourself, thus working around the cache issue so I believe Singularity already supports this scenario. Some unit tests to confirm this is the case and stays that way wouldn't hurt though. |
Do you mean creating my own |
No like this, without using the ConstructorResolvers class at all:
Then give that to the settings or registrations you pass to the container. When the resolver goes out of scope it should clear the cache. You can also remove the cache completely if desired. If you need a clearer answer. I can make a small code example later when iam at my PC |
This works.
But as it can be seen, I had to jump through some hoops as some classes or their constructors are internal. Fun fact - don't name this new
|
Ah I see, jup those constructors have to be made public Strange that the name GlobalResolver crashes visual studio, maybe its some kind of reserved name? |
Error message is very abstract so I can't really tell. This problem is tracked here: |
Released a prerelease package: https://www.nuget.org/packages/Singularity/0.17.3-addcachecleanup0003 The constructors are now public, additionally I added a Remove method to the constructor resolver cache. Still have to do more testing though but it seems this case is working now if you instantiate the resolver yourself. |
Decided to disable the caching by default. If you want to do it you can do so explicitly by creating the resolver yourself and wrapping it. This way it should be more clear when instances might be kept alive. Caching only really makes sense anyway when you keep registering the same services multiple times. |
Describe the bug
Some types used with Singularity may be a part of
AssemblyLoadContext
which holds a set of assemblies which may be then unloaded together withAssemblyLoadContext
unless something holds a reference to the assembly or one of its types. https://github.com/dotnet/docs/blob/d2ca43e5e87ca76ad737e586014b82eb7a4c3fc3/docs/standard/assembly/unloadability.md#troubleshoot-unloadability-issuesIf you use Singularity to construct a class of an unloadable assembly, Singularity (I assume) puts the compiled expression which does the heavy lifting into the global cache. However, after unloading, the type practically doesn't exist now.
There should be a way to remove a type from ConstructorResolverCache.
To Reproduce
Steps to reproduce the behavior:
Run Release build:
Expected behavior
Current behavior
The text was updated successfully, but these errors were encountered: