The Kladde’s model is in Kladde.Data, but the database doesn’t know anything about it yet. You could create the tables by hand, with the
script that GenerateCreateScript() delivers. That would work exactly once. The next time a column is added, you would have to know which
database is at which state: yours in the codespace, a colleague’s, the one in Azure. And you would have to catch up every change by hand
for each of them.
Migrations solve that. A migration is a C# class that describes exactly one step: from one state of the schema to the next. EF Core generates it from the difference between your model and the last state. The migrations live in the repository, are reviewed in the pull request like other code, and every database remembers in a table of its own which ones it already has. That way every database gets to the same state, wherever it currently stands.
The tool: dotnet-ef
Migrations are generated and applied by the command-line tool dotnet-ef. Install it as a local tool, that is with a fixed version for exactly this repository:
dotnet tool install dotnet-ef --version 10.0.14
This creates the file dotnet-tools.json in the current folder, a tool manifest with name and version. It goes into the repository.
Whoever clones the repository gets the tools from it with dotnet tool restore, and everyone works with the same version of EF Core. It is
called as dotnet ef.
For that, the startup project, that is the project with which dotnet ef starts your application, needs the package
Microsoft.EntityFrameworkCore.Design. It is needed only at development time and doesn’t go into the delivered program;
dotnet package add notes that itself with PrivateAssets in the project.