Running Entity Framework (Core) commands in Rider

A while back, we received a very interesting question: how can we run Entity Framework commands like adding migrations or updating the database, in Rider?

In Visual Studio, Entity Framework commands like Add-Migration and Update-Database are typically run in the Package Manager Console. This works great, but unfortunately, it isn’t very portable. These commands are PowerShell-based, and the Package Manager Console ties to several Visual Studio-specific objects making it impossible to host it elsewhere.

No need to worry, though! With Entity Framework Core, Microsoft provides command line tools that work cross-platform, which in this case means in any IDE on any supported operating system. Let’s see how to get started!

Adding package references

The first thing to do would be adding package references. There are a few packages we’ll be needing, the first four are typically already installed when working with Entity Framework Core:

We can add package references using the NuGet tool window or by hand-editing the .csproj file. Since there are a couple of references to add, let’s select the project in the solution explorer, Jump to Source (F4) and manually add the required package references.

Edit .csproj file using Jump to Source

(Here’s a gist if you want to copy-paste the references)

Note that Microsoft.EntityFrameworkCore.Tools.DotNet is added as a “.NET CLI tool” reference, meaning it will extend the command line dotnet command.

Once added, Rider will run a package restore and download all required packages onto our system. We can now execute Entity Framework Core commands!

Entity Framework Core commands

Commands can be run from the built-in terminal (double-shift and type “terminal”). By default, the terminal opens in our solution folder. Since the Entity Framework Core command line tools are project specific, we’ll have to cd into the project folder. To test if we’re in the correct folder, run dotnet ef. If we see an Entity Framework unicorn in ASCII art, we’re ready to go.

Usign Rider terminal to run Entity Framework command line tools

If you see an error “No executable found matching command dotnet-ef”, you may have to run a manual dotnet restore from the command line first.

Let’s start by scaffolding a new database context, using the dotnet ef dbcontext scaffold command. It takes a connection string and the driver package to use, and we’ll also give it a name:

dotnet ef dbcontext scaffold "Server=(localdb)\MSSQLLocalDB;Integrated Security=true;" Microsoft.EntityFrameworkCore.SqlServer -c AcmeDataContext

This adds a file named AcmeDataContext.cs, which implements the data context we’ll be using while developing our application. Let’s add a Person class, as well as a DbSet inside of our AcmeDataContext:

By adding the DbSet, we’re telling Entity Framework Core to include and track a set of Person objects. In other words: we’re telling it we want to store some data in a table.

We can now create an initial database migration. In Entity Framework, migrations can be executed one by one to bring a database schema to the latest version (or rollback to an older version). Let’s call it “AddPerson”:

dotnet ef migrations add AddPerson

This generates a couple of things. It’s our first migration, so a folder named “Migrations” is added to our project. Under this folder, several files are created, some of them prefixed with a number. This number is a timestamp used for ordering the migrations that will be run, making sure our database schema doesn’t get corrupted by applying migrations. These are the files on my machine:

  • 20170804084416_AddPerson.cs – the code that, in this case, creates the People table in our database and adds a primary key. We can hand-edit this one, as long as we have not applied the migration to our database yet.
  • 20170804084416_AddPerson.Designer.cs – designer information. Don’t touch it as it helps Entity Framework with some details about the migration we created.
  • AcmeDataContextModelSnapshot.cs – A snapshot of the current database model, used by Entity Framework Core to determine the database structure.

One more step: applying the database migration and bringing the database up-to-date with our model.

dotnet ef database update AddPerson

There we go: we can now use our Entity Framework Core data context in code and query, add, update and delete Person objects in there.

The dotnet ef command has some more options. Check the documentation for more info.

Connecting to our database with the Rider database tools

Working with Entity Framework is one thing, while developing we may also want to inspect the database schema or run arbitrary SQL queries against the database itself. We can do this using Rider’s database tools, which are based on our IDE for databases: DataGrip.

The database tools are available from the View | Tool Windows | Database menu (double-shift and type “database”). We can create a new database connection, and select the type of database we want to work with. In the first part of this post, we used SQL Server LocalDB, so we can add a new datasource that targets SQL Server (jTds). Do make sure to check the steps described on the DataGrip blog!

Create SQL Server LocalDB connection using jTDS

Once the connection is configured, we can see our tables and work with the data stored in there. We can export data, import data, run arbitrary queries, … A great companion to Entity Framework!

Rider database tools in action

Want to give it a try? Download Rider now! We’re eager to hear your feedback!

This entry was posted in How-To's and tagged , , , , . Bookmark the permalink.

5 Responses to Running Entity Framework (Core) commands in Rider

  1. Paul Reid says:

    Does this mean there’s no chance we’ll ever be able to use Rider for EF6 projects? If the package manager console is impossible to host elsewhere, then we’ll always need a VS license :(

  2. Pingback: Dew Drop - August 10, 2017 (#2539) - Morning Dew

  3. Chris says:

    A line in the gist file makes the ‘dotnet ef’ command return the error ‘Version for package Microsoft.VisualStudio.Web.CodeGeneration.Tools could not be resolved.
    ‘ on OSX.
    This line causes it:
    DotNetCliToolReference Include=”Microsoft.VisualStudio.Web.CodeGeneration.Tools” Version=”1.0.1″
    If you remove it or change the version to 1.0.0 it works though.

Leave a Reply

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