EF Core equals bonk - a quality Entity Framework meme right there.

“dotnet ef script” or “Script-Migration” producing empty .sql files?

This post was most recently updated on February 8th, 2022.

2 min read.

Another day, another issue. This time, I was absent-mindedly following the guidance for a project on how to generate .sql files for .NET EF Core code-first migrations. Don’t ask why that was required, but it was.

My migration was simple. Adding an entity with just a few properties. And Entity Framework created my programmatic migration just fine.

But when generating the SQL file, I got nothing but an empty file. No matter what my startup project was, – working directory, context, target folder, or other variables – the result was always just an empty file.

Let’s see if we can fix that, shall we?


Let’s assume that you’ve made some changes to your entities, and create a new migration by running this:

dotnet ef migrations add MyMigration


Add-Migration "MyMigration"

You might use other parameters. (Let’s ignore them for now).

To create a SQL script for said migration, this is the command that our documentation said that you need to run:

dotnet ef script MyMigration

Or similarly:

Script-Migration "MyMigration"

I suppose that makes sense. You run Add-Migration “MigrationName”, so of course, you run Script-Migration “MigrationName” – but as I mentioned earlier, it didn’t work.

Even running the command with -Verbose or –verbose, the output didn’t really reveal any obvious mistakes or issues. It just didn’t do… Anything.

So what to do, then?


Our internal documentation was wrong, and the commands are perhaps just a tad unintuitive.

Both dotnet ef script and Script-Migration can be called with multiple different parameter sets.

  • Either no parameters for migrations
    • in which case the script generated should be from empty to current
  • 1 migration name
    • In which case it’s treated as the FROM migration – and the SQL script will be generated from this migration to current database status.
  • 2 migration names
    • both target and source migrations. That means after creating a new migration, you’ll need to explicitly instruct the command to generate the SQL between one migration and another.


Essentially, you’ll need the name of the previous migration if you’re generating the SQL script just for the latest new migration, and the name of both FROM and TO migrations if you’re generating the script between any other migrations.

And if you’re just happy to incorporate all of the migrations into your script, you can just run the command without either.

For my case, I needed to generate the migration between 2 existing migrations. Something like shown in the guide below.

Time needed: 5 minutes

How to properly generate a SQL file from a code-first EF migration?

  1. Figure out the name of your previous migration

    You’ll need it momentarily. Grab it on your clipboard.

    Just be sure to copy it without the file extension (.cs)!

  2. Insert the name into the script below

    In this particular case, I hope the migration names are pretty obvious.

    dotnet ef script MyPreviousMigration MyMigration


    Script-Migration "MyPreviousMigration" "MyMigration"

  3. Check the generated file for any surprises!

    Before you sign off for the day, go through the generated .sql file – you’ll want to make sure nothing surprising was generated!

  4. All good now!

    Et voila!

Did it work for you? Let me know in the comments below. It did for me! ☺

5 1 vote
Article Rating
Notify of

Inline Feedbacks
View all comments