Czy jest mozliwe pobranie nazwy assembly gdzie jest wstrzyknięcie zależności?

cześć
krótko pisząc
skanuje assembly (Scrutor) a potem przy wywołaniu resolver implementuje interfejs, który ma być wstrzyknięty,

namespace ModuleA
{
    public class TestContractModuleA : BaseTestConverter
    {
        private readonly ITestContract _testContract;

        public TestContractModuleA(ITestContract testContract) : base("Test Contract AConverter")
            => _testContract = testContract;

        public override int GetValue()
            => _testContract.GetValue();
    }
}

i teraz chciałbym coś wiedzieć o tym gdzie to jest wstrzykiwane, cokolwiek, nazwę klasy, metody, assembly
ponieważ chciałbym zrobić coś na kształt context resolver przy wykorzytaniu DI kontenera z ASP.NET dlatego potrzebuję kontekstu - czyli info, gdzie aktualnie jest wstrzykanie zależności

próbuję takie coś

serviceProvider.AddTransient(serviceProvider => TestContractResolver(serviceProvider));

ale IServiceProvider nie ma takich informacji - gdzie akurat potrzebuje wstrzyknąć (albo ja nie umiem znaleźć), próbowałem coś kombinować z dodatkowym parametrem
w stylu
Assembly
CallStack

ale bez sukcesu

z góry dziękuję za pomoc

Kontener zależności chyba nie ma takiej możliwości. Może spróbuj Assembly.GetCallingAssembly()?

mussel napisał(a):

i teraz chciałbym coś wiedzieć o tym gdzie to jest wstrzykiwane, cokolwiek, nazwę klasy, metody, assembly

Pamiętaj, że takie coś prawdopodobnie będzie łamało zasadę Dependency inversion principle.

@maszrum:
dzięki za odpowiedź

no niestety nie - bo to jest Microsoft.Extensions.DependencyInjection.dll a nie dll-ka gdzie jest wstrzykiwanie

co do Dependency inversion principle.
no to jest delikatnie śliskie

ale jak masz parę implementacji danego interfejsu które zależą od jakiegoś kontekstu
to albo robisz to brzydko

czyli do obiektu wstrzykujesz wszystko i sam obiekt sobie wybiera - o z kolekcji tego chcę
a jak próbujesz ładnie - to coś musi wiedzieć co wstrzyknąć

ogólnie takie fajne rozwiązanie tego problemu widzialem w NIJECT i chciałem sprawdzic, czy jest możliwe aby osiągnać to w domyślnym IoC z Asp.Net

BTW
jak takie coś rozwiązać - jest nie wiem, parę klientów, procesów, cokolwiek co robi generalnie to samo ale na swój sposób
chcesz coś tam wstrzyknąć i masz jeden interfejs (robi to samo) i klasy go implementujące (ale na swój sposób)

No to wstrzykujesz nie implementację tego interfejsu tylko fabrykę zwracającą ten interfejs.

A to, że Microsoftowy DI jest tak biedny, że nie można nawet kontekstowo rejestrować zależności, to inna sprawa. Chociaż może to i lepiej.