EF Core Power Tools: reverse engineering a database into a DbContext from Visual Studio or the CLI

The gap EF Core Power Tools fills between a database and a working DbContext

Scaffolding a DbContext by hand is mechanical work: read the schema, write a class per table, map columns, decide on pluralization, decide on data annotations, repeat when the schema changes. EF Core Power Tools packages that loop into a dialog. The README describes the goal plainly: it "aims to lower the bar for getting started with EF Core, by providing GUI based assistance with reverse engineering of an existing database and visualizing your DbContext model."

The audience is narrower than the topic list suggests. The extension targets Visual Studio 2022, and the README states that EF Core reverse engineering with Visual Studio requires the .NET 8.0 or .NET 10.0 runtime. If your team works in Visual Studio Code, JetBrains Rider or a Linux CI container, the extension is not available to you; the README points those users at the efcpt CLI instead. That split is the single most important thing to understand before reading further, because the two surfaces are not interchangeable.

How the reverse engineering pipeline works, and where the templates sit

The repository is laid out as a Visual Studio extension plus a shared core. Top-level entries include src/, test/, samples/, docs/ and tools/. Under src/Core sits efcpt.8, the cross platform dotnet tool; the samples/ directory holds the files that control generation, with names such as efcpt-config.json, efcpt-config.schema.json, context_name.md, entitynamespace.md, pluralize.md, dataannotations.md, provider.md and databasenames.md.

That file list tells you the mechanism. Reverse engineering is driven by a configuration file plus a set of Markdown-based code templates. Each .md file in samples/ corresponds to a generation concern: the context name, the context namespace, the context path, the entity namespace and path, pluralization, data annotations, database names, and the provider. The samples/CodeTemplates/ directory holds the templates themselves. So the output is not hardcoded into the tool; you can change it by editing templates, which is the difference between this and a scaffold you run once and then hand-maintain.

Model visualization is a separate path. The README lists ErikEJ.EntityFrameworkCore.DgmlBuilder as a related NuGet package that "adds the AsDgml() extension method to any derived DbContext", producing a DGML graph viewable in the Visual Studio DGML viewer. That is a runtime call on a context you already have, not a feature of the reverse engineering dialog, and it depends on the Visual Studio viewer.

Installing EF Core Power Tools and running a first reverse engineer

The extension installs from the Visual Studio Marketplace or from the Extensions dialog inside Visual Studio. Confirm the .NET 8.0 or .NET 10.0 runtime is present first; the README lists it as a requirement for reverse engineering in Visual Studio.

For the command line, the README points to the efcpt dotnet tool and its readme under src/Core/efcpt.8. The tool is described as cross platform and intended for users who do not run Visual Studio. The samples directory includes a configuration file to start from:

{
  "$schema": "efcpt-config.schema.json"
}

The schema file samples/efcpt-config.schema.json is what you should open next to see which keys the configuration accepts; the sample above is only a starting point, and the repository, not this article, is the authority on the full key set. Generation settings that also appear as standalone sample files include pluralize, dataannotations, and provider, so those are the first knobs to look for when the default output does not match your conventions.

For a smoke test without touching a real project, the README describes a workflow used by the maintainers: launch one of the efreveng console apps in the debugger with the name of a file in the TestFiles folder as the argument. The ScaffoldingTester solution ships scripts that populate Northwind and Chinook databases with the objects those tests expect.

Where EF Core Power Tools stops short

The clearest limitation is version support. The recent releases list includes efcore6-eol, described as the last release with support for EF Core 6, and efcore-7, the last release with support for EF Core 7. If your projects are pinned to either of those EF Core versions, the tool's forward path has moved past you, and you should plan for the upgrade rather than expect new features on those branches.

The second limitation is surface parity. The README presents the Visual Studio extension and the efcpt CLI as two things for two audiences, and describes visualization through the DGML package separately again. Nothing in the README claims the CLI reproduces the extension's dialog experience or its diagram view. A team standardizing on the CLI for CI generation should verify against src/Core/efcpt.8/readme.md which options exist there before assuming a setting they use in the GUI is available on the command line.

The third is platform. Reverse engineering with Visual Studio requires Visual Studio 2022 and a specific .NET runtime. On macOS or Linux, the extension is simply not an option, and the README does not document rollback or an undo for a generation run that overwrites files you had edited.

EF Core Power Tools and dotnet ef scaffolding: templates versus one-shot generation

The obvious alternative is the built-in EF Core tooling, invoked as dotnet ef dbcontext scaffold. It is the baseline that ships with EF Core, works cross platform, and needs no extension. The difference is what happens after the first run. The built-in scaffolder emits code from the model; regenerating overwrites it, and customization generally means moving logic into partial classes or editing the generated output and accepting the conflict.

EF Core Power Tools keeps a configuration file and a template directory in the repository so that naming, namespaces, paths, pluralization and annotations are inputs to generation rather than edits to the output. That is the real distinction, and it is why the samples/ directory is full of small Markdown files instead of a single options page.

A second alternative exists for one specific source: the README lists ErikEJ.EntityFrameworkCore.SqlServer.Dacpac, which lets the standard dotnet ef tooling reverse engineer a SQL Server .dacpac. If your schema ships as a dacpac and you already use dotnet ef, that package may be a smaller addition than adopting the whole extension.

Licence, maintenance and the cost of upgrading

The repository is MIT licensed, which permits commercial use and modification; the usual obligations around preserving the licence notice apply, and this is not legal advice. Note that the licence covers the repository, while the Visual Studio extension itself is distributed through the Visual Studio Marketplace, so review the Marketplace listing if redistribution matters to you.

The last push to the default branch was on 2026-09-03, which is recent, and the repository is not archived. The project is also sponsored: the README credits AWS, which sponsored EF Core Power Tools from January 2024 via the .NET on AWS Open Source Software Fund, and thanks GitHub sponsors. Support runs through the GitHub issue tracker, and the README asks for ratings or reviews on the Marketplace.

Upgrade cost is version-bound. Because separate releases exist for EF Core 6 and 7 with an explicit end-of-line label, moving a project to a newer EF Core version means tracking the corresponding tool release. Generated code that you have edited through templates is the other cost: template changes survive regeneration, but hand edits to generated files do not, and the README does not document a rollback.

Editorial conclusion

Adopt it if you have an existing SQL Server, SQLite or other relational database and want generated entity classes you can edit through templates rather than a one-shot scaffold. Skip it if you need a supported path for EF Core 6 or 7, since the README lists efcore6-eol and efcore-7 as the last releases with that support, or if you want to generate code without Visual Studio and expect the extension's diagram view, which the CLI does not provide. Before committing, install the extension, run Reverse Engineer once against a copy of the schema, and read samples/efcpt-config.json to see which settings the CLI actually honours.

Frequently asked questions

Official sources

1. ErikEJ/EFCorePowerTools on GitHub
2. Issues
3. License: MIT
4. README
5. Releases