EF Core Part 1: Installation
Installing EF Core in a new ASP.NET Core WebAPI is simple, almost
With the release of Entity Framework Core, I’ve begun incorporating it into my personal projects so that I can be fluent in it when we enter the Core world at the office. Unfortunately, I’ve yet to go from beginning to end without some sort of issue. Maybe this is something I’m messing up, or something that is less than obvious about the setup process. In this series of posts, I will be setting up an empty project to use EF Core and troubleshooting issues that arise during the process.
I have set up EF a few times, using migrations and using an existing database. In EF 6 these were called Code-First, and Database-First, respectively. I haven’t seen those names used in reference to EF Core officially. I wouldn’t blame them for giving up on those names since the convention got a little confusing in EF 6 with Database-First, Code-First, and Database-Code-First. That last one was murder on searching for help on it since you’ll get results for all of the above. Onward! To EF Core!
Installing EF packages, what they do, why you need them, and what can go wrong
One of the things that .NET Core does in general to keep the codebase lightweight is break down formally monolithic libraries into smaller chunks. This is great for the end product, but can be a bit of a bear when setting up a new project. EF Core requires a few libraries to get it off the ground. These are:
Microsoft.EntityFrameworkCore: This is the guts of EF Core, this library supplies DbContext and DbSet, without which the whole deal is useless.
Microsoft.EntityFramework.Core.Design: Provides the basis for migration operations when creating a database from code.
Microsoft.EntityFramework.SqlServer: This contains the client that enables EF Core to talk to SQL Server. There are also SQLite libraries by Microsoft as well.
Microsoft.EntityFramework.SqlServer.Design: Provides concrete implementation of the Microsoft.EntityFramework.Core.Design function targeting SQL Server.
Microsoft.EntityFrameworkCore.Tools: This provides command line functions for scaffolding and migrations. As of the writing of this post, this is in prerelease status. If you’re using the NuGet Package Manager, you’ll need to check the “Include Prerelease” box next to the search.
Microsoft.EntityFrameworkCore.Tools.Dotnet (optional): This gives you the ability to do everything through the command line using the
dotnet command if you prefer to handle things that way. This is also in prerelease status, see the bullet above.
I’m a NuGet Package Manager-type, I do everything through the UI, so my screenshots and references will be using that. If you prefer the command line Package Manager, odds are you know how to handle these installations better than I.
After installing, if you view your references you might notice that all the EF Core references have little yellow triangles. If you open these up and drill all the way down, you might also notice that they all stem from the same library: Microsoft.Extensions.Logging. This is because I didn’t update Microsoft.NETCore.App and Mircosoft.Extensions.Logging after I created this project. After updating through the NuGet Package Manager, and doing a
dotnet restore the yellow triangles will go away.
Attempting a build at this point will lead to yet another error! This one attempts to be friendly, but is one of the more obtuse messages I’ve seen from compiler.
Yes, but what does it mean?! It turns out that Option #2 is the winner on error conditions here, and I need to do some editing to project.json. Just a wee snippet of code added to the root is all that is required:
While I’m in project.json, I’ll also want to update Microsoft.NETCore.App to 1.1.0, otherwise logging will get cranky again when I try to work with migrations or scaffolding later on.
Now everything compiles nicely! Now let’s get to actually putting EF Core to work. Here is where there is a fork in the road, I can either do Code-First or Database-First implementations of EF Core. For the sake of these post I’ll be working through both, just not in the same project.
Next Post: Migrations and Code-First