triaxis.EntityFrameworkCore.CompileModels 1.0.0

triaxis.EntityFrameworkCore.CompileModels

Compiles the Entity Framework Core model of a project at build time and puts it in that project's own assembly. Opening a context then loads the model instead of building it, which takes a fraction of the time — for a large model, well under a second instead of several.

Installation

dotnet add package triaxis.EntityFrameworkCore.CompileModels

Add it to the project that holds the DbContext. That project also needs a reference to Microsoft.EntityFrameworkCore.Design, which generating a model requires:

dotnet add package Microsoft.EntityFrameworkCore.Design

That is the whole setup. Building the project now generates the model, compiles it into the assembly, and marks it with the [DbContextModel] attribute EF Core looks for. Every process that opens the context picks it up — no consumer of the assembly has to opt in, no application code changes, and nothing generated is committed.

How it works

The generator derives the model by loading the assembly, so it cannot run until the compiler has produced one. The build therefore compiles, generates, and compiles again with the generated sources added. The second compile is only paid when something in the project actually changed: a build that skips the compiler generates nothing, and the assembly it leaves in place already carries the model from the build before it.

The model itself is generated by Microsoft.EntityFrameworkCore.Design, the same library dotnet ef dbcontext optimize calls. The package downloads nothing to do it: it ships a small program that asks Design for the model, and starts that program on the built project's own deps.json and runtimeconfig.json, so Design and everything else resolve at exactly the versions the project itself resolved. There is no tool to install, no tool manifest, and no network access during a build.

Every DbContext in the project gets a model — Design is asked for all of them. A context that cannot be constructed without services from a startup project needs an IDesignTimeDbContextFactory<T>, which is what EF recommends for generating at build time.

Options

None of these are needed for the common case.

Why not Microsoft.EntityFrameworkCore.Tasks

EF Core ships its own build-time model generation, and it does more than this package does — it can also precompile queries. It always passes --nativeaot to the generator, though, and that flavour of the model trades startup work for a much larger assembly: measured on a model of ~200 entity types, 190k generated lines against 36k, and on CoreCLR the extra IL is JIT work rather than saved work. The model loaded four times slower than the one this package generates. If your application runs on Native AOT, or you want precompiled queries, use Microsoft.EntityFrameworkCore.Tasks instead.