Resolving EF Core Primary Key Problems in Your DbContext

The useful starting point is to distinguish an entity’s missing key from a failure to create the DbContext. For an ordinary EF Core entity, use the conventional Id or TypeNameId property, or configure its key explicitly. For genuinely keyless query data, use HasNoKey() and accept its read-only behavior through EF Core. These are different remedies for different problems. [3], [2], [1]

1. Identify what actually needs a key

1. Check the entity, not the context: a key uniquely identifies an entity instance. Adding an identifier to the DbContext class is not the remedy for an entity whose identity is missing. [3], [1]
2. Choose identity deliberately: use a single-property or composite key when the data has a genuine identifier; use explicit keyless configuration when it does not. [3], [2]
3. Do not confuse tooling with mapping: migrations need to create a context at design time, but changing how the context is constructed does not define an entity’s primary key. [1], [3]

This explanation concerns Entity Framework Core. Its key convention recognizes a property named Id or <type name>Id. Thus, an Invoice with InvoiceId follows the convention, whereas a property named Number does not match those naming rules. A meaningful business name is not a substitute for explicit configuration. If Number is the intended identifier, tell EF Core that directly rather than renaming unrelated properties or changing context construction. [3]

2. Worked example: an identifier with a nonstandard name

Consider a hypothetical application in which every invoice has a unique, application-assigned Number. The class below intentionally has neither Id nor InvoiceId. The explicit HasKey mapping identifies Number as its primary key. This adapts Microsoft’s documented single-property mapping pattern; it is a model-configuration example, not a complete application or database setup. [3]

public class Invoice
{
    public string Number { get; set; } = "";
}

public class BillingContext : DbContext
{
    public BillingContext(DbContextOptions<BillingContext> options)
        : base(options) { }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Invoice>()
            .HasKey(invoice => invoice.Number);
    }
}

Alternatively, place [Key] on Number; Microsoft documents both annotation and Fluent API approaches. The important decision is the identity being declared, not which syntax you prefer. In this example, the uniqueness assumption matters: declaring a property to be the key is not evidence that existing business data satisfies that identity. Before selecting it, establish that each invoice is uniquely identified by its number. [3]

3. When identity requires more than one property

A composite key identifies an entity using a combination of properties. Microsoft’s example combines State and LicensePlate: modelBuilder.Entity<Car>().HasKey(c => new { c.State, c.LicensePlate });. This declares one composite primary key, not two independent primary keys. EF Core conventions create composite keys only in specific cases, such as an owned-type collection, so configure the combination explicitly for an ordinary entity. [3]

Also distinguish primary identity from other uniqueness requirements. Microsoft recommends a unique index when the goal is simply to enforce uniqueness. An alternate key has additional semantics because it can be the target of a foreign key. Therefore, an additional unique business field does not automatically need to replace the primary key or become part of a composite key; choose according to its role. [3]

4. Use keyless types for genuinely keyless query data

Some data has no entity identifier to configure. EF Core supports keyless entity types for SQL-query results, views without primary keys, and tables without primary keys. Configure them explicitly with [Keyless] or HasNoKey(); they are not discovered by convention. This is a distinct model category, not merely a shortcut for bypassing a missing-key problem on an entity you intend to edit. [2]

For example, Microsoft maps a BlogPostsCount reporting type using HasNoKey() and ToView("View_BlogPostCounts"), then queries it through a DbSet with ToListAsync(). Querying through a DbSet does not make the type writable: keyless instances are never tracked for changes and are never inserted, updated, or deleted by EF Core. They also cannot be the principal end of a relationship. [2]

Use the following distinctions to choose a configuration based on the type’s actual role. In particular, read-only use alone is not a reason to remove a legitimate key; keyless configuration is appropriate when the modeled query data genuinely lacks one. [3], [2]

5. Diagnose design-time context creation separately

Migrations and some other EF Core commands must create a DbContext at design time to inspect entity mappings. The tools can obtain it from application services or, if that fails, try a parameterless constructor. If an IDesignTimeDbContextFactory<TContext> is found in the context project or startup project, it takes precedence over those other creation patterns. Microsoft recommends a factory for separate migrations projects and platform-specific startup projects. [1]

The practical diagnostic is to separate constructing the context from configuring its entities. For a service-provider construction problem, inspect registration of the context and its constructor dependencies; Microsoft documents AddDbContext<TContext> and a DbContextOptions<TContext> constructor. For missing entity identity, inspect naming and key mapping instead. A design-time factory addresses construction, while HasKey and HasNoKey express different model decisions. [1], [3], [2]

Explore next

1. How should I choose between a surrogate primary key and a composite business key in EF Core?
2. When should I use a unique index instead of an alternate key?
3. How do I map a database view to a keyless EF Core entity?
4. When does a separate migrations project need a design-time DbContext factory?

Sources

Open a source or expand its cited passages.

Relevance scores are model estimates of how well each source addresses this question, not probabilities or fact-check ratings. Reasoned guidance is identified on hover.

1. 100Keyless Entity Types - EF Core | Microsoft Learnlearn.microsoft.comOfficial EF Core documentation directly defining keyless configuration, query use cases, and operational restrictions.›
2. 100Keys - EF Core | Microsoft Learnlearn.microsoft.comOfficial EF Core documentation directly covering key conventions, explicit mappings, composite keys, and alternate-key distinctions.›
3. 93Design-time DbContext Creation - EF Core | Microsoft Learnlearn.microsoft.comOfficial EF Core documentation explaining design-time context creation, useful for separating construction failures from entity-key configuration.›