Add an interface to LoggingLevelSwitch

[simonfox]

Is your feature request related to a problem? Please describe.
We use Lamar as our DI container https://github.com/JasperFx/lamar which has an Auto Wiring feature - https://jasperfx.github.io/lamar/guide/ioc/auto-wiring.html#auto-wiring

ReadFrom.Services is looking for a concrete LoggingLevelSwitch which means Lamar will provide an auto wired instance even if I don't register one. That means that if I use ReadFrom.Configration (in the recommended order before ReadFrom.Services) my minimum level in appsettings isn't respected.

Describe the solution you'd like
Add an interface to LoggingLevelSwitch and look for a that interface in the service collection - this is in alignment with the other configuration points that are resolved from services.

[nblumhardt]

Hi @simonfox!

Autowiring is talking about choosing dependent services to look up based on a type's constructor parameter list. Whether the service is available is separate, and the behavior that magically decides to make any type available for injection as a service is usually called something like "auto registration".

Unity pioneered this IIRC, but it's a wild and somewhat unpredictable feature. It would be strange for Lamar to enable auto-registration by default, at least without providing an opt-out. Perhaps the best starting point for this one is to ping the Lamar maintainers and ask whether there's an opt-out?

Cheers!

[simonfox]

@nblumhardt thanks for quick reply.

Yeah I can do registry.For<LoggingLevelSwitch?>().Use((LoggingLevelSwitch?)null);

Just banged my head for a bit until I found this and thought maybe consistently expecting an interface when using ReadFrom.Services would be worthwhile.

[simonfox]

using Lamar, GetService<LoggingLevelSwitch>() with return a value with no explicit registration i.e. it's just going I can build one of those as I know how to fill the ctor deps and its a concrete type.

[nblumhardt]

LoggingLevelSwitch is a pretty fundamental primitive that's very performance-sensitive, so even if we requested an interface we'd still likely have to down-cast to the concrete type.

If you use a container with this behavior, you do eventually hit a head-scratcher somewhere, and from that point onwards it's not so mysterious when you encounter one of these. If we made a change here, people using Lamar would just hit the next odd issue somewhere else in their dependency graph, and then be on their guard in future :)

Thanks for the suggestion, though!

[simonfox]

No worries, appreciate the insight. Funnily enough I got a similar response from Lamar maintainer in regard to Serilog ;) Love both tools!