System.InvalidOperationException: Unable to build IHost when creating EF Migration with Minimal API dotnet 6 #60891
Comments
|
/cc @davidfowl |
|
This is a tough one as we need to tradeoff how much is too much time before we give up waiting for the host builder to be created... It's possible we need an environment variable override for these cases. @ajcvickers Do you have a preference for where this gets fixed? I think we'd add support for an environment variable to override the timeout for cases like this. EF can provide a different timeout here |
|
@davidfowl I don't have strong preferences. If you provide the mechanism, we can make use of it. |
|
I can think of 2 things:
|
|
Is 5 seconds a reasonable default? Seems pretty low to me |
|
Yea, maybe it's too small. What should the default be? |
|
What are the scenarios in which we expect this to timeout? I assume that it is when the application does not actually use hosting, right? But then, more specifically for EF, the question is whether or not we have to wait for the timeout if the EF model is discovered in some other way. For example, do we have to wait for the timeout if:
I think if those two cases work without waiting for the timeout, then having a longer timeout is okay, because we will only cause slowness in real negative cases where we are going to show an error anyway. It seems like we need to do some investigation here into the user experience. /cc @bricelam |
|
The timeout is only there for this edge case: The user runs the EF tool on a .NET 6.0 application that references hosting but doesn't use it in the main entry point. Maybe its ok hanging in this scenario with a message on what the user can do? |
|
@davidfowl In that case, it seems like you can just increase the timeout significantly. If all context discovery fails, then we will output:
As shown above. |
|
Right but it wouldn't show that message. It would just hang forever unless other changes were made to show the message after some timeout |
|
@davidfowl I don't mean make the timeout infinite. I just mean increase it significantly, to say 20 or 30 seconds. It will then timeout and show the message. The user can then implement a design time context factory, in which case they can hopefully resolve the EF model quicker, or, at least, let it take as long as necessary without any timeout. |
|
Lets do that then. @eerhardt We should also change the default in the HostFactoryResolver as well (even though it's shared source). |
|
Should this issue get moved to dotnet/runtime then? Or is there a change EF should make here as well? |
|
@eerhardt As far as I know, it should move to runtime. EF will pick up the new source from there. |
|
Yep. Lets do that. |
dotnet-issue-labeler
bot
added
area-Extensions-Hosting
untriaged
|
Tagging subscribers to this area: @eerhardt, @maryamariyan Issue DetailsDescriptionI have an issue when creating ef migrations for the newest release candidate 6.0.0-rc.2.21480.5 for dotnet 6 with the minimal apis. It seems to be a similar issue as explained here dotnet/aspnetcore#33886 The timeout for creating a WebApplicationFactory at design time seems to be 5 sec and that is not enough for me when I add new migrations, because I need to setup a lot of configuration before. I get this exception when trying to run any command that requires the project to be build like The issue can be easily reproduced by creating an empty project with minimal api Include your codeusing Microsoft.EntityFrameworkCore;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContext<ApplicationDbContext>(
options => options.UseSqlServer("localhost"));
Thread.Sleep(TimeSpan.FromSeconds(6));
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();Include verbose outputOutput when building my project where the steps until builder.Build() take too long. Include provider and version informationEF Core version: 6.0.0-rc.2.21480.5
|
maryamariyan
removed
the
untriaged
maryamariyan
added
the
enhancement
|
Next to do here based on earlier conversation
is to increase timeout. On top of that we could consider adding an environment variable that could help developers set custom timeout |
|
I am running into this snag, getting the cannot create the migration: My difference is I'm using Azure AppConfiguration to retrieve my dbconnections strings, etc builder.Host
// more before
.ConfigureAppConfiguration(config =>
{
var settings = config.Build();
var connection = settings.GetValue<string>("AppConfigConnectionString");
config.AddAzureAppConfiguration(options =>
{
options
.Connect(connection)
.UseFeatureFlags(options => options.CacheExpirationInterval = TimeSpan.FromMinutes(30))
.ConfigureKeyVault(kv =>
{
kv.SetCredential(new DefaultAzureCredential(new DefaultAzureCredentialOptions { ExcludeSharedTokenCacheCredential = true }))
.SetSecretRefreshInterval(TimeSpan.FromHours(24));
})
.ConfigureRefresh(refresh =>
{
refresh
.Register("i12n:SentinelKey", refreshAll: true)
.SetCacheExpiration(TimeSpan.FromHours(4));
});
});
config.AddJsonFile("appsettings.Development.json", optional: true);
})
// more afterIf I remove the |
|
@ghorsey-opt this won't help but you can remove ConfigureAppConfiguration and just use builder.Configuration to clean up the code a bit |
|
yeah, I think I need to come up with an alternative to generate the migrations., All the connection strings from keyvault and configurations and feature flags from AppConfiguration are needed for the app. I'm toying around with the idea of creating a separate console app that has the configuration for the dbcontext and connection information locally in user secrets, then using that project as the startup project to generate the migrations... feels like a lot of extra work though. |
|
We're gonna fix the bug in a 6.0.x patch. |
|
I think the main thing we need to do is improve the exception message. I'm not sure most users want to wait 20-30 seconds to load the IHost for EF migrations. I get that's the max before it times out, but it would be nice to let developers know that reducing the time spent in Program.Main() before building the IHost will speed up migrations rather than leave people to wonder why migrations are now slower. Maybe we could consider adding a command line argument to indicate that it's being resolved by the HostFactoryResolver so developers can short-circuit unnecessary startup logic when just setting up DB services for doing migrations. We already add |
ghost
added
the
in-pr
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Description
I have an issue when creating ef migrations for the newest release candidate 6.0.0-rc.2.21480.5 for dotnet 6 with the minimal apis. It seems to be a similar issue as explained here dotnet/aspnetcore#33886
The timeout for creating a WebApplicationFactory at design time seems to be 5 sec and that is not enough for me when I add new migrations, because I need to setup a lot of configuration before. I get this exception when trying to run any command that requires the project to be build like
dotnet ef migrations add AddedPlanningSessions -vand the DbContext to be fetched from the service provider. I would expect there to be no timeout at all or at least a very large one when using WebApplicationFactory at design time.The issue can be easily reproduced by creating an empty project with minimal api
dotnet new web -o service,adding a dbcontext to the DI and adding a sleep of 6 sec.Include your code
Include verbose output
Output when building my project where the steps until builder.Build() take too long.
Include provider and version information
EF Core version: 6.0.0-rc.2.21480.5
Database provider: Microsoft.EntityFrameworkCore.SqlServer 6.0.0-rc.2.21480.5
Target framework: NET 6.0
Operating system:
IDE: VS Code Version: 1.61.1
The text was updated successfully, but these errors were encountered: