dotnet/efcore · error · InvalidOperationException

The foreign keys {foreignKeyProperties1} on '{entityType1}'

Error message

The foreign keys {foreignKeyProperties1} on '{entityType1}' and {foreignKeyProperties2} on '{entityType2}' are both mapped to '{table}.{foreignKeyName}', but with different uniqueness configurations.

What it means

Thrown by AreCompatible when two foreign keys share name and tables/columns but have different uniqueness (one IsUnique true, the other false). The database FK constraint cannot be both unique and non-unique, so EF rejects the conflict.

Source

Thrown at src/EFCore.Relational/Metadata/Internal/RelationalForeignKeyExtensions.cs:117

        {
            return shouldThrow
                ? throw new InvalidOperationException(
                    RelationalStrings.DuplicateForeignKeyPrincipalColumnMismatch(
                        foreignKey.Properties.Format(),
                        foreignKey.DeclaringEntityType.DisplayName(),
                        duplicateForeignKey.Properties.Format(),
                        duplicateForeignKey.DeclaringEntityType.DisplayName(),
                        foreignKey.DeclaringEntityType.GetSchemaQualifiedTableName(),
                        foreignKey.GetConstraintName(storeObject, principalTable.Value),
                        foreignKey.PrincipalKey.Properties.FormatColumns(principalTable.Value),
                        duplicateForeignKey.PrincipalKey.Properties.FormatColumns(principalTable.Value)))
                : false;
        }

        if (foreignKey.IsUnique != duplicateForeignKey.IsUnique)
        {
            return shouldThrow
                ? throw new InvalidOperationException(
                    RelationalStrings.DuplicateForeignKeyUniquenessMismatch(
                        foreignKey.Properties.Format(),
                        foreignKey.DeclaringEntityType.DisplayName(),
                        duplicateForeignKey.Properties.Format(),
                        duplicateForeignKey.DeclaringEntityType.DisplayName(),
                        foreignKey.DeclaringEntityType.GetSchemaQualifiedTableName(),
                        foreignKey.GetConstraintName(storeObject, principalTable.Value)))
                : false;
        }

        var referentialAction = RelationalModel.ToReferentialAction(foreignKey.DeleteBehavior);
        var duplicateReferentialAction = RelationalModel.ToReferentialAction(duplicateForeignKey.DeleteBehavior);
        return referentialAction != duplicateReferentialAction
            ? shouldThrow
                ? throw new InvalidOperationException(
                    RelationalStrings.DuplicateForeignKeyDeleteBehaviorMismatch(
                        foreignKey.Properties.Format(),
                        foreignKey.DeclaringEntityType.DisplayName(),

View on GitHub (pinned to dbf9771522)

Solutions

Align the IsUnique values: if the constraint should be unique, make both FKs unique; otherwise neither.
Give the FKs distinct HasConstraintName values when cardinality genuinely differs.
Reconcile relationship cardinality (HasOne/WithOne vs HasOne/WithMany) across the colliding FKs.
Ensure shared-table relationships are intentionally consistent before reusing a name.

Example fix

// before
modelBuilder.Entity<User>().HasOne(u => u.Profile)
    .WithOne(p => p.User).HasForeignKey<Profile>(p => p.UserId)
    .HasConstraintName("FK_Profile_User"); // unique
modelBuilder.Entity<AuditLog>().HasOne(a => a.User)
    .WithMany(u => u.AuditLogs).HasForeignKey(a => a.UserId)
    .HasConstraintName("FK_Profile_User"); // non-unique, shares table

// after
modelBuilder.Entity<AuditLog>().HasOne(a => a.User)
    .WithMany(u => u.AuditLogs).HasForeignKey(a => a.UserId)
    .HasConstraintName("FK_AuditLog_User");

Defensive patterns

Strategy: validation

Validate before calling

// Verify FKs sharing a name have the same uniqueness
foreach (var g in allFks.GroupBy(fk => fk.GetConstraintName()))
{
    if (g.Select(fk => fk.IsUnique).Distinct().Count() > 1)
        throw new InvalidOperationException($"FK {g.Key} has mismatched uniqueness.");
}

Prevention

Do not mix 1:1 and 1:many relationships under the same FK constraint name.
When changing cardinality, assign a fresh HasConstraintName.
Validate the model in tests to catch uniqueness conflicts.

When it happens

Trigger: Two sharing-table FKs resolving to one constraint name where one is configured IsUnique(true) (e.g. a 1:1 relationship) and the other is the default non-unique (1:many).

Common situations: TPH/table-splitting where base and derived entity relationships over the same FK differ in cardinality. Adding a 1:1 relationship that reuses a name from an existing 1:many FK.

Related errors

AI-assisted analysis of dotnet/efcore@dbf9771522 (2026-08-06). Data as JSON: /api/errors/db7df2b0c1bdf486. Report an issue: GitHub.