dotnet ef database update works locally but not on Azure VM

Question

I have an orchestration script that copies our legacy app's database to our new app database name in our dev environment, clones our Azure repository (GIT) for our new app and then runs the ef migrations in the cloned new app project to get our new app's database transformed from the legacy schema to our new schema and data structure.

The script works fine locally.

We have an Azure VM for running this script as a scheduled task during a pilot period while a couple customers are testing the new version and providing feedback, prior to us cutting over to the new app version.

All parts of the script are working on the VM except the running ef migrations part. The script just executes this command: dotnet ef database update --startup_project --project --connection (with the proper values being passed)

I keep getting this error when attempting to run the dotnet ef command via script or command line for troubleshooting: An error occurred while accessing the Microsoft.Extensions.Hosting services. Continuing without the application service provider. Error: There was an error parsing the Connection String: Input cannot be empty. Unable to create an object of type ''. For the different patterns supported at design time, see https://go.microsoft.com/fwlink/?linkid=851728

I have verified the dotnet tools are the same version. I have attempted to put logging statements in the file with varied but never perfect results. At one point a couple days ago while troubleshooting and as best as I can tell I hadn't made any changes, the dotnet tools started working. I had been trying other commands within the tools, like migrations list, and some others just to try to get a different result and commands started working, my print statements were actually being written to the log file and I did several tests including running the migrations and they worked! That was friday and so I thought I was good (except had no idea what changed, so that wasn't great) and I come in on monday to finish up and started by running the same command and it failed. When the commands worked there was a warning that I can't remember which didn't make me feel great but the migrations were running successfully as I verified in the database.

I'm trying to understand what could be different between the two machines and also how to go about troubleshooting.

Any tips would be greatly appreciated.

My attempts to resolve this have been mostly around trying to make sure the connection string was correct. I have used a couple approaches including using "user secrets" same as we do locally as well as setting an environment variable in the script and passing it at the command line with that --connection argument. I seem to get contradicting info about whether --connection is functional or not. Oh and the tools are version 7.0.5. We mostly stay up-to-date on .Net and NuGet versions.

Answer 1

I am posting this answer in case anyone else has this problem. The error message seems to indicate there is a problem with the DbContext's SQL ConnectionString. Everything I saw on Google indicated the same or that there was a problem with the DbContext's CreateHostBuilder and whether it was returning a WebHost or IHost, etc. Maybe my Google fu is failing. I even tried ChatGPT and it said the same thing.

I was troubleshooting this on an Azure VM with limited resources so I could not debug in Visual Studio due to memory issues and "Hard Error"s.

I fell back to using Notepad and adding print statements, ah the good ole days.

Honestly, I've never thought about what happens when you "run migrations" as in the execution order. Black box automagical...

Well now I know. I added print statements to my DbContext since that was where EVERYTHING said the problem lied. However, those were never being reached. Not even in the constructor.

So, I started adding them inside the Startup.cs and what do you know, my Configuration was working fine complete with my SQL ConnectionString.

So, I added print statements line by line to see where it blew up and Voila!

The ConnectionString that was missing was my ApplicationInsights ConnectionString. NULL Reference Exception during assignment.

I intended to keep our Configuration limited on the VM to just what was required for running the migrations and just didn't think about ApplicationInsights (or anything else in Startup.cs).

Once I added the ApplicationInsights ConnectionString to my Configuration everything worked fine.

So, the moral of the story for me, and others may already understand this, is anything inside Startup.cs can be suspect if update-database fails.

I just wish the error message was better. I always try to point the person stuck debugging my code with an error indicating where things went wrong rather than what became a misdirection for me.

Anyway, problem solved!