No project was found. Change the current working directory or use the --project option. means you ran a dotnet ef command in a folder that holds no project file. Run it from the folder of the project that contains your DbContext, or tell the tool where that project is with --project.

From a solution root that is dotnet ef migrations list --project FixEf. When the context lives in one project and the app that configures it (connection string, dependency injection) in another, add --startup-project for the app as well.

The error

PS> dotnet ef --version
Entity Framework Core .NET Command-line Tools
10.0.0
PS> dotnet ef migrations list
No project was found. Change the current working directory or use the --project option.

Why it happens

The EF Core command-line tools work on two projects. The target project, set with --project, is the one that holds the DbContext and receives new migration files. The startup project, set with --startup-project, is the one the tools build and start so they can create the context with its real configuration. Both default to the current folder. If that folder contains no .csproj, the tools have nothing to build and stop before they touch your code or your database.

The typical case is a terminal opened in the solution root or in the repository root while the project with the context sits one level down. It happens just as easily in a layered solution where you cd into a Data folder that holds only class files, not the project file.

The fix

PS> dotnet ef migrations list --project FixEf
Build started...
Build succeeded.
The Entity Framework tools version '10.0.0' is older than that of the runtime '10.0.12'. Update the tools for the latest features and bug fixes. See https://aka.ms/AAc1fbw for more information.
No migrations were found.

With the path given, the tools found the project, built it and listed its migrations (there were none yet). The version line is a separate warning: the global dotnet-ef tool was 10.0.0 while the packages were 10.0.12, and the message itself asks you to update the tool (dotnet tool update --global dotnet-ef); it does not stop the command. The same command with --project FixEf --startup-project FixEf gave identical output, because here the context and the app are one project. In a solution with a separate class library for data, the usual form is --project for the library and --startup-project for the web or console app; the startup project then needs the Microsoft.EntityFrameworkCore.Design package.

How it was reproduced

On Windows 11 with .NET SDK 10.0.401 and the global dotnet-ef tool 10.0.0, in Windows PowerShell 5.1: a console project from dotnet new console -n FixEf (target net10.0) with Microsoft.EntityFrameworkCore.SqlServer and Microsoft.EntityFrameworkCore.Design 10.0.12, one Patient entity and a ClinicContext pointed at LocalDB. Running dotnet ef migrations list from the folder above the project produced the error; adding --project FixEf fixed it. No migration was added and no database was created.

Frequently asked

How do I fix No project was found in dotnet ef?
Run the command from the folder that contains the .csproj with your DbContext, or pass that project with --project, for example dotnet ef migrations add Initial --project src/MyApp.Data.
What is the difference between --project and --startup-project in dotnet ef?
--project is the project that holds the DbContext and receives the migration files. --startup-project is the app the tools build and run to read its configuration, such as the connection string. Both default to the current folder.
Can I run dotnet ef from the solution folder?
Yes, as long as you pass --project, and --startup-project when the app is a different project. In the test above the project sat one folder down and the tools did not find it on their own.

If the tools find the project but then cannot build the context, the next message is usually Unable to create a DbContext of type. More decoded errors are in the Fixes category.