How to get an ILogger instance from extension methods?

Question

Let's say I have this service abstraction exposed from a library.

public interface INavigator
{
   ImmutableList<IPageViewModel> Entries { get; }

   void NavigateForward(IPageViewModel page);

   void RemoveEntries(int indices);

   void NavigateBack();
}

The library also exposes a default implementation that takes in an ILogger as dependency. Each method uses the logger.

public class DefaultNavigator : INavigator
{
   private ILogger _logger;

   public DefaultNavigator(ILogger logger)
   {
      _logger = logger;
   }
   
   public void NavigateForward(IPageViewModel page)
   {
      // [...]

      _logger.LogInformation("Navigated to {ViewModelName}.", page.Name);
   }

   // [...]
}

The library also exposes extensions methods on INavigator to add functionality, in the same fashion as System.Linq (where the IEnumerable<T> interface is very simple and all the core logic comes from the extension methods).

In our case, it makes sense to implement some logs in those extension methods.

public static class NavigatorExtensions
{
   public static void ReturnToRoot(INavigator navigator)
   {
      var logger = ???
      
      // [...]

      logger.LogInformation("Returned to root of navigation stack.");
   }
}

Here's the question: Where should we get the ILogger from?

What we currently have

We currently can access the IServiceProvider statically, which allows us to get an ILogger from anywhere. However, we want to move away from that public static pattern because we want to have multiple IServiceProvider instances in the same process.

Options I'm considering

1. Expose ILogger from INavigator

Does it make sense though?

public interface INavigator
{
   ImmutableList<IPageViewModel> Entries { get; }

   void NavigateForward(IPageViewModel page);

   void RemoveEntries(int indices);

   void NavigateBack();

   // This isn't related to navigation.
   ILogger Logger { get; }
}

• It doesn't feel quite right because that new member doesn't have anything to do with navigation.

2. Create a new interface that exposes an ILogger and soft cast in the extension method

// Not the best name, but I'm trying to avoid conflicts with the existing ILoggerProvider.
public interface ILoggerSource
{
   ILogger Logger { get; }
}

The extension method would do something like this:

public static class NavigatorExtensions
{
   public static void ReturnToRoot(INavigator navigator)
   {
      var logger = (navigator as ILoggerSource)?.Logger ?? NullLogger.Instance;
      
      // [...]

      logger.LogInformation("Returned to root of navigation stack.");
   }
}

• If this was the proper solution, I think ILoggerSource would already exist in MS libraries. May be it does, but I didn't see it?
• New implementations of INavigator don't have any clue that logs from extensions methods will not to work unless they also implement ILoggerSource.

3. I'm open to other options :)

Conclusion

As of writing this, I think option 1 is currently the lesser evil because it doesn't hide functionality, but my engineer mind is not satisfied.

Answer 1

The problem isn't just logging-- it's any time you want to access a service from an extension method. If you're going to use dependencies in your methods you should give them an instance.

If you want to have helper methods that do complicated stuff, then use a proper helper class, and accept the INavigator as an argument.

class NavigatorHelper
{
    protected readonly ILogger _logger;
    protected readonly IOtherDependency _otherDependency;

    public NavigatorHelper(Ilogger logger, IOtherDependency otherDependency)
    {
        _logger = logger;
        _otherDependency = otherDependency;
    }

    public void ReturnToRoot(INavigator navigator)
    {
        _logger.LogInformation("Returned to root of navigation stack.");
    }
}

//Usage
helper.ReturnToRoot(someInstance);

I get that you want to be like LINQ but LINQ's methods are all idempotent and don't mutate anything, and they only depend on what you explicitly pass them.

Answer 2

Option 3. don't use extension methods.

public class NavigatorExtension
{
   public NavigatorExtension(ILogger logger) {...}
   public void ReturnToRoot(INavigator navigator)
   {
      navigator.. whatever
      logger.LogInformation("Returned to root of navigation stack.");
   }
}

OR

public class Navigator2 : DefaultNavigator
{
   public void ReturnToRoot()
   {
      this.Whatever...
      logger.LogInformation("Returned to root of navigation stack.");
   }
}

Answer 3

A possible alternative could be to build a custom extended INavigator which includes those extension methods as ordinary methods, then extend the DefaultNavigator to use the new interface, passing the logger in:

public interface IExtendedNavigator : INavigator
{
    void ReturnToRoot(); 
    // TODO - other replacements for extension methods here
}

public class ExtendedDefaultNavigator : DefaultNavigator, IExtendedNavigator
{
    private readonly ILogger _logger;

    public ExtendedDefaultNavigator(ILogger logger) : base(logger)
    {
        _logger = logger;
    }

    public void ReturnToRoot()
    {
        NavigatorExtensions.ReturnToRoot(this);
        _logger.LogInformation("Returned to root of navigation stack.");
    }
}

This would allow any usages in your program of INavigator to be substituted by IExtendedNavigator, then replacing DefaultNavigator with ExtendedDefaultNavigator - for example:

var logger = serviceProvider.GetService<ILoggerFactory>()
            .CreateLogger(nameof(Program));
IExtendedNavigator navigator = new ExtendedDefaultNavigator(logger);

// Calls ExtendedDefaultNavigator.ReturnToRoot() instead of the extension method.
navigator.ReturnToRoot(); 

---

A word of caution - there is a potential 'gotcha' here in that code attempting to consume the ExtendedDefaultNavigator should avoid using the INavigator interface because that would fall back on the extension methods:

INavigator navigator = new ExtendedDefaultNavigator(logger);

// Warning - calls the extension method without logging!
navigator.ReturnToRoot(); 

Answer 4

New option: Use a static ConditionalWeakTable

I didn't think of this earlier but another thing that could work is use a static ConditionalWeakTable to create pairs of INavigator and ILogger.

Something like this (null scenarios could be improved, but it's just to show how it could look).

public static class NavigatorExtensions
{
    private static readonly ConditionalWeakTable<INavigator , ILogger> _loggers = new ConditionalWeakTable<INavigator , ILogger>();

    public static void SetLogger(this INavigator navigator, ILogger logger)
    {
        _loggers.Add(navigator, logger);
    }

    public static ILogger GetLogger(this INavigator navigator)
    {
        if (_loggers.TryGetValue(navigator, out var logger))
        {
            return logger;
        }

        return null;
    }


   public static void ReturnToRoot(INavigator navigator)
   {
      var logger = navigator.GetLogger() ?? NullLogger.Instance;
      
      // [...]

      logger.LogInformation("Returned to root of navigation stack.");
   }
}

Then from the startup, the INavigator would need to set its ILogger explicitly.

// [...]
var navigator = serviceProvider.GetRequiredService<INavigator>();
var logger = serviceProvider.GetRequiredService<ILogger<INavigator>>();
navigator.SetLogger(logger);

That doesn't seem too bad actually.

• Adding new extension methods can leverage the GetLogger method.
• Changes are restricted to library code and app configuration. (No changes are required in existing app library-usage code.)