This post was most recently updated on March 28th, 2023.
3 min read.Another weird, but simple issue I ran into when building a simple .NET Core application. The article should apply to pretty much any .NET Core version, but the version I was on was 2.2.
I was just minding my own business, crafting bits of code into something remotely functional, when I ran into an issue. While trying to apply my changes to the database using .NET Core Entity Framework, executing Update-Database simply failed with the following error:
The EntityFramework package is not installed
You might also encounter this version of the error:
The EntityFramework package is not installed on project [projectname here].
This error can occur with probably any of the EntityFrameworkCore commandlets. Update-Database is just the one I ran into problems with, so I’m using it as the example here.
Reason
There are apparently 2 different ways you might encounter this error. You might actually not have Entity Framework Core installed at all (in which case the solution is to install Entity Framework Core to your project), or you might do what I did and install both.
Apparently, I had inadvertently messed up my dependencies and installed not only Entity Framework Core as a direct dependency but also another package referencing Entity Framework (as opposed to the Core version of it). This caused the commandlet to be available twice – and apparently, the error for that situation is exactly the same (“The EntityFramework package is not installed”) as the one for not having the commandlet available at all!
You can verify the case by running this in your package manager console window (if you’re using Visual Studio):
Get-Module EntityFramework*
With this, you should only get a result for EntityFrameworkCore package. If you get anything else than one result, you probably have an issue.
First, the obvious one – if you don’t get anything back, run this to install the latest version of EntityFrameworkCore NuGet package on your machine:
Install-Package Microsoft.EntityFrameworkCore.SqlServer
If you get access denied errors about your PackageSource, make sure you have selected “nuget.org” (or your organization’s source) in the Package Manager’s dropdown window, or simply specify the source in the command:
Install-Package Microsoft.EntityFrameworkCore.SqlServer -Source "nuget.org"
But in case you DO get more than 1 result, you’ve got a problem. Like, a different problem. :)
Let’s look at the example output below:
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 6.0.0.0 EntityFramework {Add- EFDefaultConnectionFactory, Add-EFProvider, Add-Migration, Enable-Migrations...}
Script 2.1.1 EntityFrameworkCore {Add-Migration, Drop-Database, Enable-Migrations, Get-DbContext...}
In this case, there are 2 very different versions of Entity Framework in your project. The first one is for .NET Framework and the second one is for .NET Core. The error for having multiple versions of the Entity Framework commandlets is the same as the one for no package for Entity Framework installed at all. While not intuitive, I guess it’s understandable :)
Luckily, since this is usually not intentional, it’s easy to fix.
Solution
We now know you essentially have package conflicts in your project, and the way to fix this is to get rid of the conflicting versions of the packages. If your project is built on .NET Core, you’ll only want to have EntityFrameworkCore package, and for the Entity Framework for .NET Framework version (non-Core) one!
Wow, I hope I’m not the only one struggling to keep up with the naming conventions here…
Anyway – the solution is simple.
Time needed: 5 minutes
Get rid of the conflicting packages
- To solve this, search the Solution Explorer for “EntityFramework” – and you should actually see the package you’ve been using that refers EntityFramework instead of EntityFrameworkCore. Remove that package and use one built for EntityFrameworkCore instead!
However, this will probably not be quite enough.
- PowerShell, even when running inside Visual Studio, caches the imported modules. If you have imported a module (even implicitly), it’ll stay no matter what you do – remove the dependency, and then build, rebuild, clean – the session is still the same, and the package is there.
- Let’s kill the session to bust the cache!
Finally, long story short: restart Visual Studio. While you can probably clear the session and unload the modules other ways as well, this is the easiest solution.
After that, you should be good! :)
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
- How to close the Sidebar in Microsoft Edge - December 17, 2024
- How to stop Surface Headphones from autoplaying audio when you place them on the desk? - December 10, 2024
- “Phone Link” permanently disabled and Windows claiming “Some of these settings are managed by your organization”? (Probably) an easy fix! - December 3, 2024
