Microsoft.Extensions.DependencyInjection: Add a name to IServiceProvider to make them easier to track in complex projects

[VWilcox2000]

In large projects, particularly with hosted services with their own dependency pipelines, it can sometimes be challenging going back to older code to determine which IServiceProvider is in use for that piece of code. If there was an optional description available for IServiceCollection's extension BuildServiceProvider with say BuildServiceProvider("WebService Dependencies"), this would allow a developer to break-point any piece of code, and quickly inspect the name of its IServiceProvider to identify which service pipeline it is connected to.

[davidfowl]

I'm not opposed to this as an option on the service provider options on the default container implementation. How many DI container instances do you have and how you expect to use it? Is it purely during debugging or in memory dumps (or both?). Also this doesn't apply to scopes

[VWilcox2000]

Hi David,

I currently have 10 IServiceProvider instances which is likely above norm. I'm working on a large legacy app with around 1200 SQL database tables giving it a blazor front end talking to multiple back-ends for various database locations at a client corporation along with caching services, session state management services, and public API services, etc. EF core churns for ~40 seconds to model those tables, so for that reason alone, I have model inclusion functionality in various services that amputates joins and isolates used models to omit that huge startup delay I'd otherwise endure.

Generally, the IServiceProvider source is obvious, but yesterday, I ran into a case where a very core service for undo / redo buffer was looking for registered description providers (of undo / redo objects it gets), and I realized I wasn't sure where that particular provider came from. When this happens, I typically register it where I think it's built, debug, wait to see if fails, move the service declaration to next best guess, and so on.

Personally, after posting that yesterday, I came up with a solution for my situation, but still wonder if that is a fairly common situation other .net core developers run into worth helping them out.

If in Debug mode only, the BuildServiceProvider call would grab stack frame and store it for inspection, it would do the trick... or I thought about building a base class with various super interfaces of IServiceProvider, but settled myself on just adding a "ServiceProviderDescription" singleton to all of my service collections which works for me.

public sealed class ServiceProviderDescription
{
public string name { get; }
public string? source { get; }
public string? location { get; }

public ServiceProviderDescription(
  string name,
  string? source,
  string? location)
{
  this.name = name;
  this.source = source;
  this.location = location;
}

}

To register it, I added a helper function on top of the Microsoft.Extensions.DependencyInjection helpers in an static extension class:

public static IServiceProvider BuildServiceProvider(
  this IServiceCollection services,
  string name,
  string? source = null,
  string? location = null)
{
  IServiceProvider ret;

  ret = services
    .AddSingleton<ServiceProviderDescription>(
      new ServiceProviderDescription(
        name,
        source,
        location
      ))
    .BuildServiceProvider();
  return ret;
}

And then to identify which service provider I was looking at on demand, added another helper function:

public static void TraceDetails(this IServiceProvider serviceProvider)
{
  ServiceProviderDescription? spDesc;

  spDesc = serviceProvider.GetService<ServiceProviderDescription>();
  System.Diagnostics.Trace.WriteLine("Service Provider Details:");
  if (spDesc != null)
  {
    System.Diagnostics.Trace.Write("  Name: ");
    System.Diagnostics.Trace.WriteLine(spDesc.name);
    if (spDesc.source != null)
    {
      System.Diagnostics.Trace.Write("  Source: ");
      System.Diagnostics.Trace.WriteLine(spDesc.source);
    }
    if (spDesc.location != null)
    {
      System.Diagnostics.Trace.Write("  Location: ");
      System.Diagnostics.Trace.WriteLine(spDesc.location);
    }
  }
  else
  {
    System.Diagnostics.Trace.WriteLine("  Not Found.");
  }
}

That solved the problem for me. If my situation is uncommon, it may not be worth adding such functionality to .net core, but as it is a problem that I run into every month or two, I thought I'd throw up the suggestion for the team to consider.

Best regards,
Victor

[davidfowl]

I wonder if a more general purpose to view the gcroot hierarchy in the debugger