Efcore: Design: Discover DbContext types using Program.BuildWebHost()

[bricelam]

If ASP.NET Core adds a well known, static accessor to the IWebHost, our tools can use this to instantiate the DbContext at runtime.

We may also want to reconsider some aspects of the previous Startup-based mechanism which leaked a bit into our codebase. Specificly: environment and content root directory. This includes the --environment option on dotnet ef and ef.exe, the environment and contentRootPath parameters on OperationExecutor, and the ContentRootPath (see also #8159) and EnvironmentName properties on `DbContextFactoryOptions. Issue #7480 is also probably superseded by this.

We may also want to flow arbitrary command-line arguments into the static entry point and IDbContextFactory. But I'm not sure how we'll handle the transition from PowerShell to command-line...

This work depends on #7588

[bricelam]

As part of revisiting DbContextFactoryOptions, we can remove ContentRootPath (this was tracked by #8159)

[bricelam]

7353 may also be related to this work.

[bricelam]

We currently allow a ConfigureDesignTimeServices method to be defined on the startup class. We should consider removing that convention and only allow implementations of IDesignTimeServices.

[bricelam]

Questions we need to answer:

• Can we remove --environment and DbContextFactoryOptions.EnvironmentName? This would make Environment a Hosting-only concern.
• Can we remove DbContextFactoryOptions.ContentRootPath? This would make ContentRootPath a Hosting-only concern.
• Can we remove the logic that attempts to call <startup>.Configure<environment>Services directly? (about 600 lines of code)
• Do we try and call <startup>.ConfigureDesignTimeServices when using Program.BuildWebHost?
• How do we flow arguments into BuildWebHost from dotnet-ef/ef? From PMC?

[bricelam]

Decisions:

• Remove --environment
• Remove DbContextFactoryOptions
• Require IDesignTimeServices to be implemented before calling ConfigureDesignTimeServices
• For now, arguments will be empty at design-time. Add IDbContextFactory.Create(string[] args) to enable flowing in the future.

Still need to discuss this:

• Can we remove the logic that attempts to call <startup>.Configure<environment>Services directly? (about 600 lines of code)

[bricelam]

We will no longer attempt to call Startup.ConfigureServices directly. Use Program.BuildWebHost or IDbContextFactory instead.

[bricelam]

After #8314, #8326 & dotnet/templating#705 are merged, the 2.0.0-preview1 work for this item is done. We'll gather feedback and see if we need to do anything more in this area.

I'll file a new issue to reflect the work that was done for 2.0.0-preview1 and move this one into 2.0.0 for to follow up.

[bricelam]

Filed #8328

[bricelam]

Inlining @ajcvickers's comment.

Think we need a better message that indicates that this has happened not because they did something "wrong" but because we have made a change in how things work in 2.0. Probably with a fwlink to docs on how to convert. But happy for all this to happen later.

[bricelam]

This has evolved a bit since originally filing. The current plan is to use the interface described in aspnet/DependencyInjection#524 and not try to call Program.BuildWebHost directly.

[bricelam]

With #8510, we'll now use Program.BuildWebHost if it exists.

[shawnwildermuth]

Is there any good way to know if we're in 'design-time' since you're running the entire Startup path? I can't seem to find how to know if dotnet ef is running us instead of dotnet run. Any ideas>

[bricelam]

Implementing IDesignTimeDbContextFactory is the easiest way.

[shawnwildermuth]

So if I have both, it will use IDesignTimeDbContextFactory first if found?

[ajcvickers]

@shawnwildermuth Not currently, but see #9076, #9033, and #9073.

[bricelam]

@shawnwildermuth Yes. IDesignTimeDbContext factory will be used to construct the DbContext if it's present.

However, per the issues mentioned above, we may still (despite implementing the factory) call Program.BuildWebHost to probe for additional DbContext types in the application service provider. The workaround to avoid this is to make the BuildWebHost method private rename it.

[shawnwildermuth]

I talked about my approach (since all the examples I've seen is use the same method to build up the webhost) in my blog. It feel hacky (and I mention it as such). Feel free to burn me a little for this monstrosity. https://wildermuth.com/2017/07/06/Program-cs-in-ASP-NET-Core-2-0