dotnet/efcore · error · InvalidOperationException

The property '{1_entityType}.{0_property}' could not be foun

Error message

The property '{1_entityType}.{0_property}' could not be found. Ensure that the property exists and has been included in the model.

What it means

Thrown by OwnedNavigationStoredProcedureBuilder.CreatePropertyBuilder(string) at OwnedNavigationStoredProcedureBuilder.cs:140-141 when FindProperty(propertyName) returns null on the owned entity type. This happens when configuring a stored procedure mapping for an owned navigation and referencing a property name that does not exist on the owned entity's CLR type or model.

Source

Thrown at src/EFCore.Relational/Metadata/Builders/OwnedNavigationStoredProcedureBuilder.cs:141

    {
        var parameterBuilder = Builder.HasRowsAffectedParameter(ConfigurationSource.Explicit)!;
        buildAction(new StoredProcedureParameterBuilder(parameterBuilder, null));
        return this;
    }

    /// <summary>
    ///     This is an internal API that supports the Entity Framework Core infrastructure and not subject to
    ///     the same compatibility standards as public APIs. It may be changed or removed without notice in
    ///     any release. You should only use it directly in your code with extreme caution and knowing that
    ///     doing so can result in application failures when updating to a new Entity Framework Core release.
    /// </summary>
    [EntityFrameworkInternal]
    protected virtual PropertyBuilder CreatePropertyBuilder(string propertyName)
    {
        var entityType = OwnedNavigationBuilder.OwnedEntityType;
        var property = entityType.FindProperty(propertyName);
        return property == null
            ? throw new InvalidOperationException(CoreStrings.PropertyNotFound(propertyName, entityType.DisplayName()))
            : OwnedNavigationBuilder.Property(property.ClrType, propertyName);
    }

    /// <summary>
    ///     This is an internal API that supports the Entity Framework Core infrastructure and not subject to
    ///     the same compatibility standards as public APIs. It may be changed or removed without notice in
    ///     any release. You should only use it directly in your code with extreme caution and knowing that
    ///     doing so can result in application failures when updating to a new Entity Framework Core release.
    /// </summary>
    [EntityFrameworkInternal]
    protected virtual PropertyBuilder CreatePropertyBuilder<TDependentEntity, TProperty>(
        Expression<Func<TDependentEntity, TProperty>> propertyExpression)
    {
        var memberInfo = propertyExpression.GetMemberAccess();
        return OwnedNavigationBuilder.Property(memberInfo.GetMemberType(), memberInfo.Name);
    }

    /// <summary>

View on GitHub (pinned to dbf9771522)

Solutions

Verify the property name matches a declared property on the owned entity type exactly (case-sensitive).
Declare the shadow property first via .Property<T>("Name") before referencing it in the stored procedure.
Use the strongly-typed lambda overload instead of the string overload to get compile-time checking.

Example fix

// before: typo or wrong entity
modelBuilder.Entity<Order>()
    .OwnsOne(o => o.Details, ob =>
    {
        ob.UpdateUsingStoredProcedure(sp => sp.HasParameter("Quantitiy")); // typo
    });

// after: correct name
modelBuilder.Entity<Order>()
    .OwnsOne(o => o.Details, ob =>
    {
        ob.UpdateUsingStoredProcedure(sp => sp.HasParameter("Quantity"));
    });

Defensive patterns

Strategy: type-guard

Validate before calling

var entityType = ownedNavigationBuilder.OwnedEntityType;
if (entityType.FindProperty(propertyName) == null)
    throw new ArgumentException($"Property '{propertyName}' not found on {entityType.DisplayName()}.");
// safe to proceed with stored procedure mapping

Type guard

// Use lambda overloads for compile-time safety
void ConfigureSproc<TDependent, TProp>(OwnedNavigationStoredProcedureBuilder<TDependent> sp, Expression<Func<TDependent, TProp>> prop)
    where TDependent : class
{
    // compiler verifies the property exists
}

Prevention

Prefer lambda-based overloads (HasParameter(x => x.MyProp)) over string-based overloads to catch typos at compile time.
For string-based APIs, validate with FindProperty before calling.
Keep a unit test that verifies all stored procedure property names against the CLR type properties.

When it happens

Trigger: Calling stored procedure mapping methods like HasParameter("PropertyName") or result column configuration on an owned navigation's stored procedure builder with a string name that doesn't match any property declared on the owned entity type.

Common situations: Typo in the property name string. Referencing a property that exists on the owner rather than the owned entity. The property was renamed but the stored procedure mapping string wasn't updated. The property is shadow and wasn't declared before use.

Related errors

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