EF Core 11 adds .config/dotnet-ef.json for dotnet ef defaults
EF Core 11 lets the dotnet ef command-line tool read default options from a .config/dotnet-ef.json file. When your DbContext lives outside the startup project, you no longer need to repeat --project and --startup-project on every migration or database command. The tool finds the nearest config by walking up the folder tree, and explicit command-line flags still take precedence.
Key points
- Put the settings in .config/dotnet-ef.json with project, startupProject and optionally context.
- Paths resolve relative to the folder that contains .config, not your current directory.
- The tool walks up the tree and uses the first dotnet-ef.json it finds, so the nearest file wins.
- Explicit command-line options override values from the file.
- Set context when a project holds several DbContext types so you can drop --context from commands.
With EF Core 11, the dotnet ef command-line tool can load its default options from a .config/dotnet-ef.json file. This removes a common annoyance in solutions where the DbContext sits in a separate class library and the startup project is a Web API, because every migration or database command previously needed both project flags spelled out.
The file's project, startupProject and optional context values are resolved relative to the folder that holds .config, not the current directory. The tool searches upward from where you run it and uses the first match. Flags typed on the command line always override the file, so one-off changes do not require editing it. Each area of a larger solution can keep its own file, and the nearest one wins. Check the original post and the EF Core 11 documentation for the remaining supported properties.
Real-world use
- Migrating a shared DbContext in a class library used by several ASP.NET Core APIs without repeating project flags.
- Simplifying CI scripts that run dotnet ef database update by pinning project paths in one config file.
- Keeping separate defaults for independent areas of a monorepo, such as two unrelated APIs with their own DbContext.
Why it matters
In solutions where the DbContext is outside the startup project, dotnet ef commands get much shorter and scripts simpler, and path mistakes from typing long flags become less likely.