Migrations Bundles

We currently have dotnet ef migrations script and database update to apply migrations. Unfortunately, they each have their shortcomings.

migrations script is pretty good at producing SQL scripts (there are some known issues with the scripts), but figuring out what to do with those scripts may not be obvious. Publish from Visual Studio wraps these scripts up in a web deployment package and uses MSDeploy to run them on the server. This works well for SQL Server on Windows, but nothing else.

database update is a lot better at applying migrations. It doesn’t have any of the issues the SQL script does. Unfortunately, it requires the .NET Core SDK, your app’s source code, and a direct connection to the production database. Having all of these things available where you need them is’t always possible.

I propose we introduce a new migrations bundle command. This would create a self-contained EXE that you could use to apply migrations. It would behave the same as database update and let you specify the connection string. This would make SSH/Docker/PowerShell deployment a lot easier. You wouldn’t need to copy your source files to a server inside the firewall and you wouldn’t need to install the .NET Core SDK. Here is an example of what it might look like to use SSH:

dotnet ef migrations bundle
scp bundle [e-mail]:./
ssh [e-mail] "./bundle --connectionString ${DEPLOYMENT_CONNECTION_STRING}"
ssh [e-mail] "rm bundle"

Taking this further, Visual Studio could do all of this for you like they do today on MSDeploy but when you’re deploying to Docker. They could even create a new SSH deployment experience.

---

TODO

• Add --output to allow renaming the bundle
• Match TargetFramework, RuntimeIdentifier, and SelfContained of startup project by default
  • Add --no-self-contained
• --self-contained doesn’t work

  error NETSDK1031: It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier. You must either specify a RuntimeIdentifier or set SelfContained to false.

• --runtime doesn’t work between Windows and other OSes. We look for *.exe based on the current runtime instead of the target runtime.
• Add automated tests
• Add --force to overwrite an existing bundle #25271
• Refine command output #25274
• --configuration and --runtime optoins are repeated in help

[bricelam]

📢 Status update

I got an end-to-end working. There are still a lot of details to sort out before sending a PR…

[bricelam]

dacpac is perfect for DB-first; keep using it there. However, it’s fundamentally different from Migrations which are designed for a code-first workflow. Also, dacpac is SQL Server-only and a big part of these bundles is to improve the experience when using other databases like PostgreSQL, MySQL, and Oracle.

Fun fact, the first prototype of Migrations was based on dacpac.