EF Core does not automatically add every class in your project to its model. An entity generally enters through a DbSet<TEntity> property, an explicit modelBuilder.Entity<TEntity>() call, or a navigation property from an entity already included. If something appears to be missing, first determine whether it is absent from the EF model, present but mapped unexpectedly, or present in the model but omitted from a migration. Each points to a different fix.
First identify what is missing
“EF Core is not detecting my entity” can describe three different problems. Inspect the model EF actually built before changing mappings or generating another migration.
As an Amazon Associate I earn from qualifying purchases.
- Absent from the model: EF has no entity metadata for the type. Check its inclusion route and whether it was explicitly excluded.
- Present, but mapped unexpectedly: The entity exists in the model, but its table, properties, or relationships do not match your expectations. Review conventions, attributes, and Fluent API configuration.
- Present in the model, absent from migration operations: Migration output is not a complete list of model entities. The table may be excluded from migrations, or the migration may have no schema change to apply.
EF Core documents entity inclusion and migration exclusions separately in Entity Types and its Migrations Overview.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteCheck how EF Core includes the type
A class being public, located beside other entities, or compiled into the same assembly does not by itself add it to the model. For each missing type, verify that the context actually in use includes it through one of the documented routes:
#1 Best Overall
- A
DbSet<TEntity>property on that context. - An explicit
modelBuilder.Entity<TEntity>()call in itsOnModelCreatingmethod. - A valid navigation property from an entity that is already included; EF recursively discovers related types through navigation properties.
For example, explicit registration can look like this:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Invoice>();
}Use the context your application or migration tooling really constructs. Registering an entity in a different context will not add it to the model being inspected.
Do not confuse configuration scanning with entity discovery
ApplyConfigurationsFromAssembly(...) finds and applies implementations of IEntityTypeConfiguration<TEntity>. That is a way to apply mapping configuration; it is not a general scan that adds every class in the assembly as an entity.
Recommended Free Tools
Likewise, an EntityTypeConfiguration attribute does not independently cause EF Core to discover its entity type. The type must first be included in the model. See Creating and Configuring a Model for configuration methods and their precedence.
Check exclusions and inheritance
Look for explicit exclusion
modelBuilder.Ignore<TEntity>() and the [NotMapped] attribute exclude a type from the model. Remove or revise the exclusion if the type should be modeled.
Do not mistake ExcludeFromMigrations() for an entity exclusion. It leaves the entity in the EF model while telling migrations not to manage that mapped table. That setting is appropriate when the context uses a table but another process or context owns its schema.
For TPC, include every type in the hierarchy
If the missing type is part of an inheritance hierarchy mapped with table-per-concrete-type (TPC), explicitly include every type in that hierarchy, using DbSet properties or Entity<T>() calls as appropriate. EF Core 7 documentation notes that this differs from the derived-type discovery behavior associated with legacy EF6; do not assume EF6 rules apply. See What’s New in EF Core 7.0.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Inspect the model before changing the database
EF Core’s model debug view lets you examine the metadata it built. Compare that view with your intended entities and mappings: it can show whether a type is absent or present with a different configuration. The modeling documentation describes the debug view and configuration behavior.
When the type is present but mapped differently, consider configuration precedence. Fluent API configuration in OnModelCreating takes precedence over data annotations and conventions. If multiple Fluent API calls conflict, later calls override earlier ones. An unexpected mapping can therefore result from an override rather than failed discovery.
Rank #4
Compare the runtime model with migration output
EF Core generates migrations by comparing the current model with the previous model snapshot. A migration records schema changes relative to that snapshot; it is not an inventory of every entity. If an entity is in the model but a migration has no operation for it, check the table’s migration-exclusion setting and whether the snapshot and current model actually differ.
Also verify that design-time tooling used the intended context and configuration. A separate migrations project is supported, but its provider and design-time model configuration should be consistent with runtime configuration. See Using a Separate Migrations Project.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Use the right extension point for scaffolded contexts
Database-first reverse engineering generates partial entity and context classes. The generated context calls OnModelCreatingPartial after its generated OnModelCreating configuration. Put durable additions or overrides in the partial extension point rather than editing generated files that a later scaffold may overwrite. The Reverse Engineering documentation explains these extension points.
Investigate model caching only when model shape varies
EF Core builds and caches a model; it does not rerun OnModelCreating for every instance of a context type. This matters when the same context type intentionally produces different model shapes based on context state. In that specialized case, the model cache key must distinguish the variants, typically through IModelCacheKeyFactory. See Alternating between multiple models with the same DbContext type.
For an ordinary missing entity, check inclusion and exclusions first. Model-cache customization is relevant only when the model is deliberately supposed to vary for the same context type.
Quick Recap
A practical diagnostic order
- Inspect the built model. Decide whether the entity is absent or present with unexpected mapping.
- Verify the context. Check that the application or design-time tooling is using the context you changed.
- Trace inclusion. Look for a
DbSet, explicit registration, or a navigation from an included entity. - Review exclusions and inheritance. Check
Ignore,[NotMapped], migration exclusions, and—in TPC hierarchies—explicit inclusion of every type. - If only a migration is missing, inspect the snapshot and design-time setup. Confirm the model difference and that migration configuration matches the intended context.
- If the context is scaffolded, use its partial extension point. If the model intentionally varies by context state, then investigate cache-key customization.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
