2
votes

I have two configurations: - Development - Production

with following json settings files: - appsettings.Production.json - appsettings.Development.json

In each settings file I have following sections:

(production)

"Sql" : {
    "Name": "App_Prod",
    "Server": "127.0.0.1",
    "Port": 0,
    "Database": "db_prod",
    "Username": "user_prod",
    "Password": "secret"
   },

(development)

"Sql" : {
    "Name": "App_Dev",
    "Server": "127.0.0.1",
    "Port": 0,
    "Database": "db_dev",
    "Username": "user_dev",
    "Password": "secret"
   },

I'm injectings these into my DbContext constructor, and it works properly. I updated my database using migrations system using foolowing command:

dotnet ef database update --context MyDbContext--configuration Development

it worked, and my database scheme has been updated.

But when I'm trying to update my production database using following commanad:

dotnet ef database update --context MyDbContext--configuration Production

it gaves me information that any migrations no needs to be applied.

I dumped connection string in MyDbContext, and I can see that the DbContext still use Development configuration even I type that it should be use Production settings file.

Why migration mechanism does not respect my configuration? How I can run dotnet ef with appsettings.Production?

2
I would use an env var to provide the connection string instead of appsettings.Production.json. If you use the config file, afaik you'll have to set the environment name before execution the dotnet cli command as described here docs.microsoft.com/en-us/aspnet/core/fundamentals/… (--configuration != environment name). Set ASPNETCORE_ENVIRONMENT=ProductionChristoph Lütjen
I tried to use you solution before, but there were any results. Its wired because, when I'm trying to apply migration, build process creates Production directory with only production settings.bielu000
It seems that you mix up debug / production build configurations with different environments. The first is "how it's compiled" but environments are about settings. That means, you can create a production build and run it with development settings and a debug build and run it with production settings.Christoph Lütjen
What @ChristophLütjen said. In fact, ASP.NET Core doesn't technically utilize the configurations in Visual Studio at all. Instead of compiling for a particular configuation environment as in older versions of ASP.NET, the configuration environment is specified via settings, usually via the environment variable ASPNETCORE_ENVIRONMENT.Chris Pratt

2 Answers

0
votes

--configuration is for build configuration (e.g. Release, Debug)

Pre-v2.0:

Use -e or --environment:

PM> dotnet ef database update --context MyDbContext -e Production

v2.0+:

Set ASPNETCORE_ENVIRONMENT environment variable before executing command:

PM> $env:ASPNETCORE_ENVIRONMENT='Production'

0
votes

In my case(Linux environment) using:

export ASPNETCORE_ENVVIRONMENT=Development

changes environment used by database update command