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.