Scrutor
Scrutor copied to clipboard
Is it possible to load from solution assemblies only?
I am facing an issue related to how my application is organized and I am quite lost on how to solve it. Would like to know if there is a way around this issue.
Before, I used to have only a single project that was called service that would reference multiple other libraries. When registering my dependencies using scrutor, I would simply register them in the right order and everything was fine.
The issue is now that I refactored the code base to have a more complex structure, and now it became really hard for me to register my dependencies in the right order.
I need to register it in the right order because sometimes on my service I want to overwrite a default implementation of an interface from a library. For example the repositories. If I inject an IRepository<TestEntity> I want it to resolve the DefaultRepository<TestEntity> or, if my service implements a custom repository, the CustomTestRepository<TestEntity>.
Now, I was basically registering it using the following logic that existed in the library:
// this resolves to my library assembly
scan.FromCallingAssembly()
.AddClasses(classes => classes.AssignableTo(typeof(IRepository<>)))
.AsSelfWithInterfaces()
.WithScopedLifetime();
// this resolves to my service assembly and will basically overwrite the above
scan.FromEntryAssembly()
.AddClasses(classes => classes.AssignableTo(typeof(IRepository<>)))
.AsSelfWithInterfaces()
.WithScopedLifetime();
The issue is that now that I have multiple other projects on my service level solution, and using FromEntryAssembly doesn't work anymore. I have tried FromAssemblyDependencies and FromApplicationDependencies and, although they return all assemblies I need, it is really hard to ensure the order is correct for resolution.
Am I doing this right? Any suggestions on how to deal with it? I didn't want have to manually look for assemblies using string matching.
Hi @vdurante! 👋🏻
My suggestion is to maybe be more explicit in your registrations and avoid scanning the entire solution. But a lot of people like this, so I can't blame you.
I think I have a solution for #183 which will probably ship in the next version of the library. Do you think that could help your scenario?