Entity Framework Core tools reference - .NET Core CLI

The command-line interface (CLI) tools for Entity Framework Core perform design-time development tasks. For example, they create migrations, apply migrations, and generate code for a model based on an existing database. The commands are an extension to the cross-platform dotnet command, which is part of the .NET Core SDK. These tools work with .NET Core projects.

When using Visual Studio, consider using the Package Manager Console tools instead of the CLI tools. Package Manager Console tools automatically:

• Works with the current project selected in the Package Manager Console without requiring that you manually switch directories.
• Opens files generated by a command after the command is completed.
• Provides tab completion of commands, parameters, project names, context types, and migration names.

dotnet ef can be installed as either a global or local tool. Most developers prefer installing dotnet ef as a global tool using the following command:

dotnet tool install --global dotnet-ef

To use it as a local tool, restore the dependencies of a project that declares it as a tooling dependency using a tool manifest file.

Update the tool using the following command:

dotnet tool update --global dotnet-ef

Before you can use the tools on a specific project, you'll need to add the Microsoft.EntityFrameworkCore.Design package to it.

dotnet add package Microsoft.EntityFrameworkCore.Design

Run the following commands to verify that EF Core CLI tools are correctly installed:

dotnet ef

The output from the command identifies the version of the tools in use:

                     _/\__
               ---==/    \\
         ___  ___   |.    \|\
        | __|| __|  |  )   \\\
        | _| | _|   \_/ |  //|\\
        |___||_|       /   \\\/\\

Entity Framework Core .NET Command-line Tools 2.1.3-rtm-32065

<Usage documentation follows, not shown.>

Use dotnet tool update --global dotnet-ef to update the global tools to the latest available version. If you have the tools installed locally in your project use dotnet tool update dotnet-ef. Install a specific version by appending --version <VERSION> to your command. See the Update section of the dotnet tool documentation for more details.

Before using the tools, you might have to create a startup project or set the environment.

The commands refer to a project and a startup project.

• The project is also known as the target project because it's where the commands add or remove files. By default, the project in the current directory is the target project. You can specify a different project as target project by using the --project option.

• The startup project is the one that the tools build and run. The tools have to execute application code at design time to get information about the project, such as the database connection string and the configuration of the model. By default, the project in the current directory is the startup project. You can specify a different project as startup project by using the --startup-project option.

The startup project and target project are often the same project. A typical scenario where they are separate projects is when:

• The EF Core context and entity classes are in a .NET Core class library.
• A .NET Core console app or web app references the class library.

It's also possible to put migrations code in a class library separate from the EF Core context.

The CLI tools work with .NET Core projects and .NET Framework projects. Apps that have the EF Core model in a .NET Standard class library might not have a .NET Core or .NET Framework project. For example, this is true of Xamarin and Universal Windows Platform apps. In such cases, you can create a .NET Core console app project whose only purpose is to act as startup project for the tools. The project can be a dummy project with no real code — it is only needed to provide a target for the tooling.

Why is a dummy project required? As mentioned earlier, the tools have to execute application code at design time. To do that, they need to use the .NET Core runtime. When the EF Core model is in a project that targets .NET Core or .NET Framework, the EF Core tools borrow the runtime from the project. They can't do that if the EF Core model is in a .NET Standard class library. The .NET Standard is not an actual .NET implementation; it's a specification of a set of APIs that .NET implementations must support. Therefore .NET Standard is not sufficient for the EF Core tools to execute application code. The dummy project you create to use as startup project provides a concrete target platform into which the tools can load the .NET Standard class library.

You can specify the environment for ASP.NET Core projects on the command-line. This and any additional arguments are passed into Program.CreateHostBuilder.

dotnet ef database update -- --environment Production

Any additional arguments are passed to the application.

Deletes the database.

Options:

The common options are listed above.

Updates the database to the last migration or to a specified migration.

Arguments:

Options:

The common options are listed above.

The following examples update the database to a specified migration. The first uses the migration name and the second uses the migration ID and a specified connection:

dotnet ef database update InitialCreate
dotnet ef database update 20180904195021_InitialCreate --connection your_connection_string

Gets information about a DbContext type.

The common options are listed above.

Lists available DbContext types.

The common options are listed above.

Generates a compiled version of the model used by the DbContext and precompiles queries.

See Compiled models for more information.

Options:

The common options are listed above.

The following example uses the default settings and works if there is only one DbContext in the project:

dotnet ef dbcontext optimize

The following example optimizes the model for the context with the specified name and places it in a separate folder and namespace:

dotnet ef dbcontext optimize -o Models -n BlogModels -c BlogContext

Generates code for a DbContext and entity types for a database. In order for this command to generate an entity type, the database table must have a primary key.

Arguments:

Options:

The common options are listed above.

The following example scaffolds all schemas and tables and puts the new files in the Models folder.

dotnet ef dbcontext scaffold "Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -o Models

The following example scaffolds only selected tables and creates the context in a separate folder with a specified name and namespace:

dotnet ef dbcontext scaffold "Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -o Models -t Blog -t Post --context-dir Context -c BlogContext --context-namespace New.Namespace

The following example reads the connection string from the project's configuration set using the Secret Manager tool.

dotnet user-secrets set ConnectionStrings:Blogging "Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=Blogging"
dotnet ef dbcontext scaffold Name=ConnectionStrings:Blogging Microsoft.EntityFrameworkCore.SqlServer

The following example skips scaffolding an OnConfiguring method. This can be useful when you want to configure the DbContext outside of the class. For example, ASP.NET Core apps typically configure it in Startup.ConfigureServices.

dotnet ef dbcontext scaffold "Server=(localdb)\mssqllocaldb;Database=Blogging;User Id=myUsername;Password=myPassword;" Microsoft.EntityFrameworkCore.SqlServer --no-onconfiguring

Generates a SQL script from the DbContext. Bypasses any migrations.

Options:

The common options are listed above.

Adds a new migration.

Arguments:

Options:

The common options are listed above.

Creates an executable to update the database.

Options:

The common options are listed above.

Checks if any changes have been made to the model since the last migration.

Options:

The common options are listed above.

Lists available migrations.

Options:

The common options are listed above.

Removes the last migration, rolling back the code changes that were done for the latest migration.

Options:

The common options are listed above.

Generates a SQL script from migrations.

Arguments:

Options:

The common options are listed above.

The following example creates a script for the InitialCreate migration:

dotnet ef migrations script 0 InitialCreate

The following example creates a script for all migrations after the InitialCreate migration.

dotnet ef migrations script 20180904195021_InitialCreate

• Migrations
• Reverse Engineering
• Compiled models