Skip to content

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

Closed
@aspnet-hello

Description

@aspnet-hello

From @divega on Tuesday, May 2, 2017 5:16:21 PM

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 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

Copied from original issue: aspnet/DependencyInjection#524

Metadata

Metadata

Assignees

No one assigned

    Labels

    Needs: DesignThis issue requires design work before implementating.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions