Troubleshooting the dotnet ef command for EF Core Migrations

Updated March 7, 2017 after Visual Studio 2017 was released.
Also, keep in mind that I have been updating this post (and will continue to do so) as I discover new ways people are hitting problems with dotnet ef.

When using EF Core in a .NET Core app (ASP.NET Core or other app sitting on .NET core), it’s easy to run into a problem when attempting to use EF Core migrations at the command line. The most common one is

No executable found matching command "dotnet-ef"

A Note If Your Coming from My Pluralsight EF Core Course

Microsoft supports developing .NET Core apps in VS2017. The tooling for VS2015 is outdated and there are no plans to bring them up-to-date for the new csproj support. I recorded my Entity Framework Core: Getting Started  course on Pluralsight while VS2017 was still in beta. While I did recreate the VS2017 demos in RC3 right before we published the course, we chose to leave the  rest of  the .NET Core demos that are in VS2015 alone.  VS2015 only supports project.json and the project templates set you up for .NET Core 1.0, not .NET Core 1.1. So in the course means that we’re stuck with project.json support and tooling that’s not quite aligned. But Pluralsight and I both agreed that it made sense not to ALSO force users to the bleeding edge, not even released VS2017 for the demos. The course’s focus is on EF Core, so as long as I could hand-hold users through the project.json setup stuff without the need to make them expert at that, it was the right way to go.

Of the nearly 2000 who have already watched the course since it’s release less than 2 weeks ago,  a few people ran into some confusion with the versioning and getting the “no executable found” message. I worked through these with them but wanted to write down the suggestions I’d made and have a single blog post I could point to.

Problems You May Encounter with ‘dotnet ef’

While some of these notes are specific to the project.json use in the course, I’ve also added tips for using dotnet ef with the newer csproj/msbuild support.

There are a few key things to watch out for.

  1. The current stable tooling for EF Core migrations is split into two packages.
         Microsoft.EntityFrameworkCore.Tools is for PowerShell
        Microsoft.EntityFrameworkCore.Tools.DotNet is for the CLI (dotnet commands)
    Be sure you’ve referenced the Tools.DotNet version of the package so that you have access to the CLI commands. If you’re following my course, that’s explained.
  2. dotnet ef only works in .NET Core projects. If your project targets the full .NET framework, then you’ll need to use the PowerShell commands e.g. add-migration, update-database.
  3. Make sure that you are running the command from the folder that contains the project where the Tools package is referenced. This is explained in the course demos, but still a step you may overlook in your excitement!
  4. If you are using project.json*, make sure that you have the Tools.DotNet package in the Tools section, not the dependencies section. After March 7 release, this will just be “1.0.0”.
    *Going forward, you should only be using project.json with .NET Core 1.0 projects. If you are using the current .NET Core (1.1+) you should be using csproj/msbuild.

    "tools": {
       "Microsoft.EntityFrameworkCore.Tools.DotNet": "1.0.0"
  5. If you’re using csproj/msbuild, make sure the tools package is listed in the DotNetCliToolsReference tag.  After March 7 release, this will just be version “1.0.0”.

        Version=”1.0.0” />
  6. If you’re using csproj/msbuild, make sure the casing is correct if you’re manually adding that package in csproj! I’ve seen people get tripped up by typing Dotnet rather than DotNet.
  7. It’s possible that you have to Tools correctly placed but your IDE did not trigger a dotnet restore. So you may need to do that manually. Here’s an example where that bit someone.
  8. You shouldn’t be using an RC of VS2017 at this point but I’m leaving this one here.
    If you are using an older Release Candidate of Visual Studio 2017 (before RC3) , the CLI tooling was not yet aligned with the msbuild support so with that version, you have to use the PowerShell commands to do migrations. Therefore you have to use the Tools package and work in the package manager console, not the command line.

        Version="1.1.0-preview4" />

    As of  VS2017 RC3 (which is what I show in the last module of the course) it was possible to use msbuild3 as shown in point #4 above and the CLI commands. After March 7 release, this will just be “1.0.0”.

  9. Be sure you’re targeting a relational database. Migrations only work with those and not, for example, InMemory. A twitter friend accidentally ran into this problem and was getting the “no executable found” error message.
  10. Make sure that the version of the EF Core tools you are using aligns with the version of .NET Core on your machine.

In my EF Core course, I’m using EF Core 1.1 and for EF tools and in all but the last module, I’m using Microsoft.EntityFrameworkCore.Tools.DotNet 1.0.0-preview4. (I’m in the process of  updating the course to use the new 1.0.0 package)

You’ll need .NET Core 1.1 installed and the related dotnet SDK – which is not numbered as simply. Today the  .NET Core SDK tools are still in preview so the version number of the current “stable” build that goes with .NET Core 1.1 is 1.0.0-preview2-1-001377.  

Note that on March 7  when VS2017 has its official release, the .NET Core SDK tools will also be released so the versions will just be normal numbers like 1.0.0.

Here’s an example of what the dotnet ef command will tell you if you don’t have .NET Core 1.1 installed:

The specified framework 'Microsoft.NETCore.App', version '1.1.0' was not found.
 - Check application dependencies and target a framework version installed at:
 C:\Program Files\dotnet\shared\Microsoft.NETCore.App
 - The following versions are installed:
 - Alternatively, install the framework version '1.1.0'.

You can get the correct version via the download grid at The grid only exposes stable releases. If you’re looking for nightly builds (which at this time you need for using the csproj support), there’s a link to those just below the grid.

The set of downloads you get via the LTS button is for .NET Core 1.0.3. The Current button gives you the latest stable versions. The SDK button gets you the Runtime + SDK, whereas the Runtime button gives you ONLY the runtime.

The SDK installs will give you the SDK and the runtime. When you’ve selected the SDK set of installs, it says that it’s .NET Core 1.0. That’s referring to the version of the SDK. It will also install both the .NET Core 1.0 and .NET Core 1.1 runtimes. That single SDK is able to work with both of the runtimes. I’m on Windows x64 so my download is the first one on the list…the Windows x64 installer.netcoresdk10

Just as an FYI, if you select the Runtime set of downloads, then you will only be getting a specific version of a runtime and not the SDK.


After it’s installed, typing dotnet will show you that you the runtime version that your machine is running by default. That’s the later one. After installing the 1.0 SDK with both runtimes, dotnet tells me I’m running Version 1.1.0 of the runtime. 

 dotnet –version gives you the version of the SDK. That’s already showing me that there was a patch because the result says “1.0.1”.

If you installed this new SDK but are still seeing the old SDK version (1.0.0-preview2-001313), that is likely because that version is specified in the global.json file of your solution. That shouldn’t create a problem for using the migration commands, but it’s a good idea to have the correct version listed in global.json.

Some additional tips for you!

Commands can only run from an executable/test project

In my Pluralsight EFCore course, I have the DbContext in its own class library project. So when running dotnet ef, after solving all of the above problems, you’ll get a new message which is just pointing out that the commands depend on an executable to run. That message looks like this:

Could not invoke this command on the startup project 'TestEFCore.Data'. This version of the Entity Framework Core .NET Command Line Tools does not support commands on class library projects in ASP.NET Core and .NET Core applications.

In my case, I wasn’t ready to add a UI or test to the solution,  so I added a minimal console app just to cover this need. And it needs to reference the project with the DbContext. Once that’s sorted, you can use the —startup-project parameter of the dotnet ef command to point to that project. While I show all of this in my course, you can also see that in my MSDN Magazine article here:

This will get a touch easier with the msbuild version of the EF Core tools. With the newer tooling, you’ll at least be able to run dotnet ef to get the command’s help without pointing to a startup-project, although to run sub commands, you’ll still need to specify the startup project.

Installing the EF Core Tools via NuGet in Visual Studio 2015

One of the viewers of the course reported a strange problem. He was able to add the EF Core Tools package in project.json and use the migrations from the CLI as expected. But if he attempted to add the package from the NuGet Package Manager or the Package Manager Console instead, he was back to the old ‘No executable found matching command “dotnet-ef”‘ error.

He finally noticed that there were errors when NuGet attempted to download the package. But in his IDE the errors were subtle, so he was unaware that the tools package was not installed. Here’s a screenshot he shared:


I figured out how to get myself into a similar bind and got a much more helpful error message:


Package 'Microsoft.EntityFrameworkCore.Tools.DotNet 1.1.0-preview4-final' uses features that are not supported by the current version of NuGet. To upgrade NuGet, see

Even though Visual Studio extension manager did not indicate an available update AND it listed my NuGet Package Manager version as 3.5 (the latest), I learned that the team responsible for this extension had temporarily stopped pushing notifications for updates! That change is noted in the “No Auto Updates” section of this blog post:

So I had to explicitly download the latest VSIX (ignoring the fact that it seemed to have the same version # as the one I had installed!) from the NuGet  distributions page. After installing that, it resolved the problem of installing the EF Core tools package from the Package Manager and Package Manager Console.


There’s a sneak peek at EF Core with msbuild in VS2017

A few people mentioned to me that they decided to go straight to VS2017 when working through the demos in the course. And they also said they were confused by some differences and had to do some research. I know for sure that one of these devs was kicking himself when I asked if he had watched the VS2017 demo I did at the end of the course before trying to VS2017 along with the early demos. (His answer was “umm, now you tell me!”)  It’s listed in the table of contents for the course. So if you take a peek at that first, I think doing all the demos in VS2017 will be a lot easier! I am currently in the process of updating the VS2017 demos to use the RTM and latest tools.

Hope this helps!

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!  

19 thoughts on “Troubleshooting the dotnet ef command for EF Core Migrations

  1. 1. Created ASP.NET Core Web API in VS 2017
    2. Used EF Core In-Memory provider to work with DbContext. Hadn’t installed Sql Server yet, was in process
    3. CRUD with In-Memory worked fine in Web API, Sql Server installation completed
    4. Now removed EF Core in-memory provider, added EF Core Sql Server package, set connection string
    5. Started EF migration, this didn’t work (our tweet conversion). DotNet tools msbuild also present.
    6. Created a fresh ASP.NET Core Web API in VS 2017, added EF Core Sql Server package, connection string etc.
    7. Started EF migrations, everything worked well. Created migration folder, created database also, even performed Web API CRUD.

    Above steps I followed, not sure why this issue but everything about your PS course & blog post is perfect.

    Thanks a lot for valuable time !!

  2. Thank you for explaining this, it helped me a lot! Just one question… I’ve been using dotnet cli for ef with VSCode, I usually add EF packages using “dotnet add package …”, but I can’t do that with “Microsoft.EntityFrameworkCore.Tools.DotNet”, I have to do it manually in .csproj file so it can be added as a tool and not a package:

    Do you know if there’s a dotnet cli command to add “Tools.DotNet” as a tool and not a package?


    1. Interesting you should ask because I just discovered that you can’t add the Tools.DotNet package from the Package Manager in VS2017. you have to do it manually … editing the csproj file. See this github issue I added less than an hour ago: My guess is that for the same reasons, the dotnet cli commands can’t handle it either but I’m going to ask on that same issue.

  3. As part of your revamp for VS2015 release (7Mar17) you should also update the “Exercise files” (aka which has latest files of 2Feb (except *.PDF of 10Feb17).
    “EF Core 1.1Visual Studio 2015 Update 3This course will get updated for future EF Core”
    is obviously still on the ToDo: list. I will keep a look out for updates as re-ploughing an old furrow is not popular choice imho, and the world (well at least 2000 PS subscribers you noted) awaits ! TIA

    1. I’ve made the changes and am waiting for Pluralsight to publish them. I didn’t redo every demo since most of it is for plain .NET anyway and fine in VS2015. But many and made it VERY clear where things changed, where they did’t and why. If I redid all the demos, it would have taken a month to get this done and out. I will do a totally new course …all in VS2017 for full .NET and .NET Core demos.

  4. whoops I meant VS2017 release
    (I blame my muscle memory after 2 years of CTP, previews and RCs). Now have to re-educate for .csproj.
    My brother suggests that “how is it that everything I like doing is illegal, immoral or fattening?” should have “or causes cancer in rats” appended.
    I suggest that the “the only certainties are death and taxes” should have ” and new software versions that are breaking changes and need fundamental and painful re-learning” appended.
    “If I Had More Time, I Would Have Written a Shorter Letter” [quote]

  5. In your PS course=”Entity Framework Core Getting Started” module=”Creating a Data Model and Database with EF Core” clip=”Creating the Data Model”: you recommend Mads K’s “Add New File” extension. I have 2 problems with this
    1. there are several issues including ignoring VS settings for tabs etc
    2. utterly unnecessary as you can easily add class with Shift+Alt+C
    (if you really wanted to demo menu keystrokes you could do Alt P,C)

    if you agree, in your re-recording please suppress such off-topic extras as IMHO it confuses the EF message. TIA

  6. The dotnet cli package version of these tools seems really slow. In PowerShell, Windows command line or Visual Studio Code’s terminal window, entering something like dotnet ef migrations –help consistently takes 6 seconds to respond. Is this normal?

  7. I’ve been trying to swap the in-memory database from this tutorial:

    … to LocalDB, but when I run `dotnet ef migrations add InitialCreate -v`, I get…

    fail: Microsoft.EntityFrameworkCore.Database.Command[20102]
    Failed executing DbCommand (7ms) [Parameters=[], CommandType=’Text’, CommandTimeout=’30’]
    SELECT 1
    FROM [TodoItems] AS [t])
    System.Data.SqlClient.SqlException (0x80131904): Invalid object name ‘TodoItems’.

    But I thought the first migration would *create* the tables. Why would it fail because the table I’m getting ready to make hasn’t been made?

    Full details here:

    1. (adding as reply now that I see the previous post; you might want to moderate the duplicate post)

      To answer my previous question (that’s in the moderation queue; sorry to leapfrog it, sorta), you can’t run a migration script (at least not an initial one) with a DatabaseContext that seeds data, like the tutorial I was following did for its in-memory db…

      if (_context.TodoItems.Count() == 0)
      _context.TodoItems.Add(new TodoItem { Name = “Item1” });

      Take out the data seeding, and dotnet ef migrations works nicely.

  8. To answer my previous question (that’s in the moderation queue; sorry to leapfrog it, sorta), you can’t run a migration script (at least not an initial one) with a DatabaseContext that seeds data, like the tutorial I was following did for its in-memory db…

    if (_context.TodoItems.Count() == 0)
    _context.TodoItems.Add(new TodoItem { Name = “Item1” });

    Take out the data seeding, and dotnet ef migrations works nicely.

  9. Somehow my Project file (myproject.csproj) removed the reference I had (Microsoft.EntityFrameworkCore.Tools.DotNet) put when I restarted the solution, so I put it again and reloaded the solution without closing it.

    Another thing I noticed is that the command needs the internet to be on the machine to run. I added the -v switch to the command in order to see more detailed execution and noticed that it was trying to connect to the internet.

  10. Pingback: ASP.NET Blog
  11. Pingback: .NET Blog
  12. Hi Julie,
    First a fall excellent articles on EF core.

    Can you please help me with an error that I am facing while adding migrations in my project? Details are mentioned below:

    *All about my project setup:
    Versions used:
    1. ASP.Net core 2.2
    2. EF core 2.2

    I have installed all the necessary packages to enable EF core (v2.2)

    The migrations worked fine in my project when I had no Seeding logic in my program.cs. But once I made changes to the
    ” public static IWebHost (**and not IWebHostbuilder**)CreateWebHostBuilder(string[] args)”

    is when my migrations started failing.Below is the error stack trace while I was trying to add migrations

    An error occurred while accessing the IWebHost on class ‘Program’. Continuing without the application service provider. Error: Object reference not set to an instance of an object.

    Unable to create an object of type ‘AceEntities’. For the different patterns supported at design time, see

    I tried searching a solution for this but with no success.
    Can you please suggest a work around?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.