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

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

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?

Problem

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

Or:

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?

Reason

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.

Solution

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.

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

• Author
• Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)

• How to output all Environment Variables in Azure DevOps with PowerShell? - April 9, 2024
• CSOM suddenly throwing exceptions when trying to access list contents in SharePoint? A weird fix. - April 2, 2024
• “Predefined type ‘System.Object’ is not defined or imported” and other System namespace stuff missing in your solution? - March 26, 2024