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

[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

[aspnet-hello]

From @davidfowl on Tuesday, May 2, 2017 7:53:12 PM

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

[aspnet-hello]

From @DamianEdwards on Tuesday, May 2, 2017 7:55:12 PM

Sure, where should we put it?

[aspnet-hello]

From @davidfowl on Tuesday, May 2, 2017 7:58:37 PM

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

[aspnet-hello]

From @divega on Tuesday, May 2, 2017 10:37:12 PM

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.

[aspnet-hello]

From @ericwj on Monday, May 15, 2017 3:49:15 PM

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

[aspnet-hello]

From @Eilon on Monday, May 15, 2017 4:28:27 PM

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

[aspnet-hello]

From @ajcvickers on Monday, May 15, 2017 4:32:25 PM

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

[aspnet-hello]

From @ericwj on Tuesday, May 16, 2017 5:39:07 AM

Can you comment a bit on bringing some UI folks onboard? Xamarin, UWP? Is this something you see benefit in? Or should I raise this issue in a few other places?

[aspnet-hello]

From @bricelam on Tuesday, May 16, 2017 11:28:03 AM

@ericwj It's worth raising in the respective places.

I think it's a little less interesting with MVVM because most people probably aren't using Microsoft.Extensions.DependencyInjection.Abstraction there like we do in ASP.NET Core.

[aspnet-hello]

From @ericwj on Tuesday, May 16, 2017 12:36:55 PM

No, not today, but behold, .NET Standard is coming. I don't think there is mention of a date for UWP to arrive at 2.0, but once it's there, it'll make quite an impact I'm sure. Sharing basics like this just removes friction and making switching project types less of a culture shock. And it'd be opt in anyway I'm sure...

I've tried to find a suitable repo for XAML, but I couldn't really find one. Can you direct me somewhere, or should I use Provide a suggestion... from VS and post it at https://visualstudio.uservoice.com?

[aspnet-hello]

From @bricelam on Tuesday, May 16, 2017 12:58:44 PM

VS Feedback would be a good place to start. Maybe dotnet/project-system would also get the right people looking at it.

[aspnet-hello]

From @ericwj on Tuesday, May 16, 2017 1:13:15 PM

And Xamarin? They don't have issues. Only pull requests 🥇

[aspnet-hello]

From @bricelam on Tuesday, May 16, 2017 1:21:23 PM

Sorry, no idea on that one

[aspnet-hello]

From @ericwj on Tuesday, May 16, 2017 1:22:37 PM

TY anyway, I'll get there

[aspnet-hello]

From @divega on Friday, May 19, 2017 10:02:46 AM

Clearing up milestone so that this can be re-triaged. We are not planning to do it for 2.0.0. Also some relevant comments in the conversation on the PR: aspnet/DependencyInjection#527 (comment).

[aspnet-hello]

From @muratg on Friday, October 20, 2017 10:41:54 AM

@divega What milestone should this go in? 2.2 or backlog?

[aspnet-hello]

From @divega on Monday, October 23, 2017 11:26:19 PM

@muratg I think it is fine for this to be in the backlog. It still seems nice and from time to time we hear from people that want something that works with DI without ASP.NET Core and without going all the way down to IDesignTimeDbContextFactory, but it does not seem to be a high priority.

Cc @bricelam and @ajcvickers in case they think we should plan to have it sooner.

[davidfowl]

@divega Do you think we still need this? I'm going to close this out since we have something else that seems to be working fine. Come talk to me if you really really want it 😄