Interface to formalize how tooling obtains the application's service provider

[divega]

This a more general purpose alternative to the feature described in dotnet/efcore#8331.

Currently tools that require access to the application's runtime services and configuration (e.g. EF Core tools, ASP.NET Core Scaffolding, possibly Razor tooling and others) need to hardcode heuristics which

• often require for tools to take additional unwanted dependencies, e.g. EF tools brings ASP.NET Core Hosting in 1.0 even if it can be used in non-ASP.NET Core applications
• only work if the application follows specific (often version-specific) conventions to build the service provider (e.g. Startup.ConfigureServices() in ASP.NET Core 1.0, Program.BuildWebHost() in ASP.NET Core 2.0, etc.)
• and require restoring to bespoke fallback mechanisms (like IDbContextFactory in EF) if the convention is not matched

This issue is about defining a common accessor interface that tooling can scan for at design time which provides access to the application's service provider. We believe this approach:

• Could be used in ASP.NET Core applications as well as any other application that uses our DI
• Could be leveraged by any tool that requires access to the application's services, rather than being component-specific
• Removes the need of hardcoding heuristics in tools by moving the necessary code to the application
• Enables project templates can incorporate an implementation of the interface that is tailored to the patterns they used to construct the application's service provider, e.g. for the ASP.NET Core 2.0 templates the implementation can return Program.BuildWebHost(args).Services. If the mechanism changes in the future, the template can be updated
• Addresses all the concerns described in Design: Allow open generic implementations of IDbContextFactory dotnet/efcore#8331, e.g. it allows EF Core tooling to discover any DbContext registered with AddDbContext regardless of their location, making IDbContextFactory unnecessary for most common cases

Example:

public class DesignTimeServiceProviderAccessor : IDesignTimeServiceProviderAccessor
{
    public IServiceProvider GetServiceProvider(string[] args)
        => Program.BuildWebHost(args).Services;
}

Open issues:

• Still need to run the idea by the architect 😄
• General shape and naming of the interface (or abstract type?) is up in the air
• Need to decide where we want to put it in templates

cc @bricelam @ajcvickers @DamianEdwards @davidfowl

[davidfowl]

I don't see what this has to do with DI. Are we just looking for a place to put an interface?

[DamianEdwards]

Sure, where should we put it?

[davidfowl]

Honestly, I don't understand what this solves... Are we going to have shared code that calls into this interface or something?

[divega]

Not necessarily, but yes we could.

As the title says and hopefully the description explains this interface formalizes the convention that tools need to implement in order to obtain the application's service provider at design time. E.g. instead of having to fake a host and instantiate Startup to call ConfigureServices() based on yesterday's templates, calling Program.BuildWebHost() based on tomorrow‘s templates, whatever we come up in the future or however customers decide to factor their code, we establish that tools will look for a type implementing this interface in the startup project and we start including one by default in the templates.

The main affinity with DI is that it is about obtaining the IServiceProvider. I guess it could go instead in a tooling abstractions package if we had such thing.

[ericwj]

It is an interesting idea for Universal apps as well. There is always the problem of being unable to instantiate ViewModels at design time which have constructor arguments that are meant to come from DI at runtime. Everybody goes about crafting a solution, and they aren't always pretty. Sometimes they're awful. This isn't about 'tooling' per se, not in the .NET Core sense, but how cool would it be if XDesProc could use this? Well, phase one would be me using this with if (DesignModeEnabled)...

[Eilon]

@divega @davidfowl @ajcvickers @DamianEdwards @muratg @bricelam - what is the status of this? We met last week, and I thought maybe we arrived at a conclusion, but I don't recall the concrete next steps. Whatever we decide, we should try to get it in this week.

[ajcvickers]

@Eilon Diego, Brice, and I talked about it a little while ago. Brice is going to send some pull requests and we will take it from there.