8

I am trying to run Update-Database, and I would like to specify the connection string, but the CLI is looking at the wrong one. There are two connection strings in my appsettings.json file:

{
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "ConnectionStrings": {
    "LocalWindows": "data source=.\\SQLEXPRESS;initial catalog=Intranet;persist security info=True;integrated security=true;",
    "AzureDevelopment": "Server=tcp:en..."
  }
}

When I run Update-Database, AzureDevelopment is always the key it uses. So if I copy the LocalWindows connectionstring to AzureDevelopment's value, it updates the correct database. Furthermore, if I delete AzureDevelopment but leave LocalWindows like this:

{
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "ConnectionStrings": {
    "LocalWindows": "data source=.\\SQLEXPRESS;initial catalog=Intranet;persist security info=True;integrated security=true;"
  }
}

I get:

Value cannot be null.
Parameter name: connectionString

So it seems at some point, the CLI chose to use the AzureDevelopment string, and I can no longer change the key or supply the connection string as an argument.

My question is how does the migrations CLI know what connection string to use? Is it detecting the string through some reflection magic on the startup settings or what? All I see online is how to specify the project when running Update-Database. There used to be -ConnectionString and -ConnectionStringName parameters for the CLI, but those are no longer available.

Cymricus
  • 350
  • 2
  • 8
  • is there only one appsettings.json file or do you have multiple for different environments? – Martin Ullrich Jan 28 '18 at 11:36
  • There were five environment-specific appsettings files. I solved the issue by setting the env variable in the console right before running update-database. I couldn’t set it globally in Windows and it ignored the appsettings files for some reason. – Cymricus Feb 02 '18 at 17:48

2 Answers2

14

All I had to do was the following in PowerShell:

$env:ASPNETCORE_ENVIRONMENT='LocalWindows' dotnet ef database update

or

$env:ASPNETCORE_ENVIRONMENT='LocalWindows' Update-Database

Turning on verbose with Update-Database -verbose also shows you the environment in the output to make sure it's hitting the correct one.

What doesn't work:

  • Setting a global ASPNETCORE_ENVIRONMENT environment variable in Windows
  • Setting the ASPNETCORE_ENVIRONMENT environment variable in the Project->Settings->Debug screen
Cymricus
  • 350
  • 2
  • 8
  • 1
    Thank you so much, this is the answer i have been hunting for days. Switching between 'Development' and 'Production' is now allowing me to easily migrate both a local and a remote database. – jv_ Mar 19 '18 at 12:08
  • 1
    verbose helped assure me that my Development environment was targeted, however its still looking at the base appsettings.json and not appsettings.Development.json. any help would be great – jgritten May 13 '22 at 23:21
  • @jgritten you need to set the env var to whatever the json name is so in this case appsettings.Development.json, the env is Development, that second part of the filename, assuming youre using out of the box Core code. try calling $env:ASPNETCORE_ENVIRONMENT='Development' then dotnet ef database update – Cymricus Jul 07 '22 at 17:18
2

In EF Core 5.0, it is possible to specify the connection string like this:

dotnet ef database update --connection "<connection string>"
Assaf S.
  • 4,676
  • 2
  • 22
  • 18