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.
If you want to change the connection string go to the app. config and remove all the connection strings. Now go to the edmx, right click on the designer surface, select Update model from database, choose the connection string from the dropdown, Click next, Add or Refresh (select what you want) and finish.
Let's use Update-Database to apply this migration to the database. Run the Update-Database command in a Package Manager console. Code First Migrations will compare the migrations in our Migrations folder with the ones that have been applied to the database.
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:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With