小开

Sometimes when you install a new version of dotnet sdk, it hits the PATH.

You have to manually add the folder .dotnet/tools from your home directory to PATH.

小开

最佳答案

Note to readers: If you haven't installed dotnet ef, you need to install it first: dotnet tool install --global dotnet-ef. The question-asker already did that. You need to do that first before the rest of this answer can help.

How to fix this

For Linux and macOS, add a line to your shell's configuration:

bash/zsh:

export PATH="$PATH:$HOME/.dotnet/tools/"

csh/tcsh:

set path = ($path $HOME/.dotnet/tools/)

When you start a new shell/terminal (or the next time you log in) dotnet ef should work.

For Windows:

See this question on how to add to the PATH environment variable.

You need to add %USERPROFILE%\.dotnet\tools to the PATH.

What's going on?

The .NET Core 3.0 (preview) version of this failure is much more illuminating:

$ dotnet ef
Could not execute because the specified command or file was not found.
Possible reasons for this include:
* You misspelled a built-in dotnet command.
* You intended to execute a .NET Core program, but dotnet-ef does not exist.
* You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.

The second and the third one both refer to dotnet trying to find a dotnet-ef command but can't find it. As the third point says, dotnet-ef is not in your path.

Here's what the docs say:

Global Tools can be installed in the default directory or in a specific location. The default directories are:

OS Path

Linux/macOS $HOME/.dotnet/tools

Windows %USERPROFILE%\.dotnet\tools

So, you should add $HOME/.dotnet/tools/ to your $PATH.

But also note this part from docs:

These locations are added to the user's path when the SDK is first run, so Global Tools installed there can be called directly.

So, it sounds like something went wrong. If you installed using a manual tarball, the SDK screwed up and you should report this bug to Microsoft. If you use a distribution package, they screwed up and you should report this as a bug to them.

小开

In my case, the tools folder didn't exist inside %USERPROFILE%\.dotnet\ so I had to run the command dotnet tool install --global dotnet-ef to install dotnet ef. Then I was able to run dotnet ef...

This was the result of the above install command:

小开

For those who encountered the issue after updating their Visual Studio or .NET Core package this is due to updates made in .NET Core 3 by removing dotnet ef from .NET Core and making it a separate package which can be installed via:

dotnet tool install -g dotnet-ef

For reference see this answer and this breaking change

小开

I have tried all the previous answers, and it didn’t work on my Mac with the latest macOS v10.15 (Catalina) update.

If you are using .NET Core 3 version for instance, you need to run these commands:

export PATH="$PATH:$HOME/.dotnet/tools/"
export DOTNET_SKIP_FIRST_TIME_EXPERIENCE=false
export DOTNET_ADD_GLOBAL_TOOLS_TO_PATH=true


dotnet tool install --global dotnet-ef --version 3.0.0

小开

dotnet ef database update

If the above command gives you an error, please follow the below steps.

check path %USERPROFILE%.dotnet\ exists or not
if not then run the below command
```
dotnet tool install -g dotnet-ef
```
Now again check the path and set the environment variable for the below path
```
%USERPROFILE%\.dotnet\tool
```
Now in cmd, set the path where your database context file is present and then run the below command
```
dotnet ef database update
```

Note: It worked me for .NET Core 3.0.

小开

For anyone struggling with this issue on JetBrains Rider, I tried all the solutions listed on this page and eventually went into Visual Studio and ran the dotnet tool install --global dotnet-ef --version 3.0.0 command there and then reopened in Rider and it worked.

小开

Regarding the path fix:

Be aware this adds the path to the User PATH, not the System PATH environment variable. When firing off a "Developer Command Prompt" or "Developer PowerShell" from Visual Studio, it does not use the User path variable. You'll need to add it to the System environment variable as well.

Also, you'll need to restart Visual Studio Code before the change takes effect.

小开

This is due to updates made in .NET Core 3 by removing dotnet ef from .NET Core and making it a separate package.

You need to add %USERPROFILE%.dotnet\tools to the PATH.
If it does not exist, then run this command:
```
dotnet tool install -g dotnet-ef
```

小开

I had the same issue on Ubuntu 20.04.1 with the .net Core 5.0.0-rc.1 and the solution that worked for me was to install the dotnet ef as a local tool

https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools#install-a-local-tool

dotnet new tool-manifest
dotnet tool install  dotnet-ef --version 5.0.0-rc.1.20451.13

小开

TL&DR: dotnet tool install -g dotnet-ef

Rationale: See the announcement for ASP.NET Core 3 Preview 4, which explains that this tool is no longer built-in and requires an explicit install.

Reference: https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-3-0-preview-4/

小开

For me, closing the solution and restarting Windows solved the issue. But before that we need to follow the below steps to check if installation is done properly or not.

Run the below command. If you don't see dotnet-ef then you proceed to step 2, else, go to step 3.
```
dotnet tool list --global
```
Go to path, %USERPROFILE%\.dotnet\tools and check if dotnet-ef is there or not. If not then you might need to run
```
dotnet tool install --global dotnet-ef --version 3.1.4
```
I believe you have already done this.
Add this path %USERPROFILE%\.dotnet\tools to your environment variables, to see if you get it in your project or not.
At last, you need to close your project and restart the window. In my case, this step solved the problem.

小开

With EF Core 6.0 we can generate EF Bundles - MSDN

This solves above problem, the bundle can be run as regular executable file and will apply migrations. Just make sure you have your appsettings.json or secrets.json if using UserSecrets package along with generated binary.

user@shell~$ ./efbundle


PS> efbundle.exe

Project --project and --startup-project can also be specified just as with regular migrations

PS> dotnet ef migrations bundle --self-contained -r linux-x64 --project .\MyApp.Shared  --startup-project .\MyApp.ApiClient

I believe we should be able to also specify --connection your_connection_string here but I didn't try.

找不到命令“ dotnet ef”

How to fix this

What's going on?