Efcore: dotnet ef Doesn't Respect ASPNETCORE_ENVIRONMENT Value

[robbpriestley]

Steps to reproduce

1) Set the ASPNETCORE_ENVIRONMENT environment variable to production
2) Refresh the terminal session and ensure that the environment variable is set properly: echo $ASPNETCORE_ENVIRONMENT
3) Add a new migration ex: dotnet ef migrations add mig3 --context MyContext
4) Update the database dotnet ef database update --context MyContext

The issue

Database update runs on development, not on production. I believe the dotnet ef database update command should respect the environment variable. I have found that all other dotnet commands do. To get the update to run on production, I need to "hack" my secrets file secrets_development.json and substitute the production connection string for the development connection string. The path to the correct secrets file is set in the startup method and derived based on the environment variable as follows:

var builder = new ConfigurationBuilder()
.SetBasePath(env.ContentRootPath)
.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
.AddJsonFile($"secrets_{env.EnvironmentName}.json", optional: false)
.AddEnvironmentVariables();

Configuration = builder.Build();

Further technical details

EF Core version: 1.0.0
Operating system: MacOS
Visual Studio version: Code
Database: PostgreSQL

[neyromant]

If I understand correctly, you have to explicitly specify the environment.

https://docs.efproject.net/en/latest/miscellaneous/cli/dotnet.html#dotnet-ef-database-update

Usage: dotnet ef database update [arguments] [options]

Arguments:
[migration] The target migration. If '0', all migrations will be reverted. If omitted, all pending migrations will be applied
...
-e|--environment The environment to use. If omitted, "Development" is used.

[robbpriestley]

Ah. I just assumed that the ef command would follow the same pattern as the other dotnet commands. I don't have any new migrations to run right now, but I will try this next time. I think the issue can be closed.

[mikebridge]

I agree this is confusing. It'd be nice if all the dotnet commands ran the same way---seems strange that one accepts an environment variable and one a command line parameter.

[bricelam]

Dupe of #7353