New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EF Core Drop Database Command runs the "ConfigureServices" method twice #10636

Closed
mindingdata opened this Issue Jan 3, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@mindingdata

mindingdata commented Jan 3, 2018

Running a drop database command in Entity Framework Core runs the "ConfigureServices" method twice in an ASP.net Core application. I'm sure this could cause a myriad of issues but in my particular case, something that is being called in ConfigureServices uses a static variable which should only be set once, when it's set a second time the application crashes and the ef command fails.

Steps to reproduce

I have created a complete project to replicate the issue. That project can be found here : https://github.com/mindingdata/EFConfigureServices

Couple of things to note about the project. It uses a MSSQL Server located on localhost using integrated security. Connection String is located in the ConfigureServices method if you need to change this to replicate the issue.

The ConfigureServices method itself has the following :

static bool hasRan = false;
public void ConfigureServices(IServiceCollection services)
{

	if (hasRan)
	{
		throw new Exception("Configure services has run twice");
	}

	hasRan = true;

	services.AddMvc();
	var connection = @"Server=.;Database=efconfigureservices;Trusted_Connection=True;ConnectRetryCount=0";
	services.AddDbContext<MyContext>(options => options.UseSqlServer(connection));
}

This is just a simple replication of the issue, but as I say, I ran into this issue in particular when using the popular mapping library "Automapper" which uses static variables to hold configuration.

When the command dotnet ef database drop is run on this project, the ConfigureServices, and I assume possibly other parts of the code, are executed twice. This then throws an exception in some cases where code isn't expecting to be run more than once.

I do not get the same issue when creating migrations or updating the database using the dotnet ef cli.

Further technical details

Tools version of "*".
EF Core version 2.0.1
Database Provider: Microsoft.EntityFrameworkCore.SqlServer (Originally replicated using npgsql/postgres)

@bricelam

This comment has been minimized.

Show comment
Hide comment
@bricelam

bricelam Jan 6, 2018

Member

Looks like this will only happen on .NET Core since .NET Framework isolates each call inside its own AppDomain.

The reason we're doing it twice is because the logic looks like this:

  1. Get the database name (first ConfigureServices call)
  2. Prompt about dropping the databse
  3. Drop the database (secondConfigureServices call)
Member

bricelam commented Jan 6, 2018

Looks like this will only happen on .NET Core since .NET Framework isolates each call inside its own AppDomain.

The reason we're doing it twice is because the logic looks like this:

  1. Get the database name (first ConfigureServices call)
  2. Prompt about dropping the databse
  3. Drop the database (secondConfigureServices call)
@bricelam

This comment has been minimized.

Show comment
Hide comment
@bricelam

bricelam Jan 6, 2018

Member

(P.S. I'm just adding notes so we can triage this better.)

Member

bricelam commented Jan 6, 2018

(P.S. I'm just adding notes so we can triage this better.)

@ajcvickers

This comment has been minimized.

Show comment
Hide comment
@ajcvickers

ajcvickers Jan 9, 2018

Member

Notes from triage: this should be made to work when --force is used since in that case there is no need to get the database name for the prompt. We may get to this in 2.1, but also marking as up-for-grabs since it should be a relatively simple change that somebody from the community could do.

Member

ajcvickers commented Jan 9, 2018

Notes from triage: this should be made to work when --force is used since in that case there is no need to get the database name for the prompt. We may get to this in 2.1, but also marking as up-for-grabs since it should be a relatively simple change that somebody from the community could do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment