Design: Allow IDesignTimeDbContextFactory to short-circuit service provider creation

[ajcvickers]

Implement some way to specify/find a DbContext and IDesignTimeDbContextFactory such that BuildWebHost is never called even if it is present. This should allow a clean escape hatch to be used when building the service provider has side effects that the app needs to prevent.

See discussion in #9033

[bricelam]

Workaround

To prevent EF Core from calling Program.BuildWebHost(), rename it.

[aghe]

Just comment what is in Configure() from Startup when you use the tools for migrations.

[bricelam]

Is there an issue in Hosting that we should report here? If we only ever access the service provider from the IWebHost, why is it calling Startup.Configure()?

[aghe]

From what I see at a quick look on the code BuildWebHost will always call that.

There is a method there seems that is called in BuildWebHost

private static ConfigureBuilder FindConfigureDelegate(Type startupType, string environmentName)
    {
      return new ConfigureBuilder(StartupLoader.FindMethod(startupType, "Configure{0}", environmentName, typeof (void), true));
    }

Maybe I'm wrong

[divega]

@bricelam AFAIR there was a conversation about this around the preview 1 timeframe when there was an exception thrown because there was no certificate to run the web host in production mode. Our general feedback was that the call to .Build() was doing way too much work eagerly which intuitively seemed to belong in .Run().

If this doesn't change .Build() will still really be a poor choice of an entry point for design time.

@glennc said he would follow up on that. Not sure if issues have been filed.

[ajcvickers]

@divega to follow up with @glennc and/or hosting.

[hikalkan]

I have a seed code on Startup.cs file which throws exception since there is no database. It should not run Program.cs if there is a IDesignTimeDbContextFactory implementation.

[ajcvickers]

Note from triage: this hasn't shown itself to be a major problem so far, so we are closing this issue for now. If you hit this then please provide some feedback on this issue and we will re-assess based on the feedback.

[Jarrich]

It's unclear to me how this is not a major problem with an easy fix.

I didn't know or expected this behavior, so every time I ran "dotnet ef database update" all my configuration would load, a connection would be made to my RabbitMQ instances etc etc... causing the migration to fail if something went wrong there.

Please re-consider.

[bugproof]

Can't you just check if there's IDesignTimeDbContextFactory implemented and if not fall back to calling BuildWebhost?

[GF-Huang]

Any solution ?

[eavonius]

I don't understand how this is closed. It's still a problem! My app does configuration value verification at startup and those values are blank when migrations are scripted during a build because I don't want secrets checked into source control. They get set only at release time, when the migrations have already been generated and packaged in the build artifact.

[bricelam]

@eavonius Can you create a new issue? We could avoid app service discover entirely if...

1. You specify the fully-qualified name of the DbContext type, and
2. There is an IDesignTimeDbContextFactory or paramaterless constructor for that type.

[Rene-Sackers]

Workaround

To prevent EF Core from calling Program.BuildWebHost(), rename it.

My apologies for commenting on such an old and closed issue, but with .NET/EF 6, it seems I'm back to 0 regarding this problem.
Renaming the BuildWebHost worked great before, but with 6 and the new minimal config, there is no BuildWebHost method anymore, and even if I change my code to use the old method with a Startup.cs and everything again, it seems to just be calling Main() no matter what, even though I have an IDesignTimeDbContextFactory for my context.

What is the suggested way of preventing the dotnet ef tooling from launching my entire webapp from Main() when it tries to make a migration?
In my particular case, I apply any pending migrations on app startup from Main (or the generated Main function, where you don't define a class in Program.cs), and I'd like it not to when running the dotnet ef tools.

[ajcvickers]

@Rene-Sackers See #27322.