dotnet/efcore · error · InvalidOperationException

Could not find symbol for method invocation: {invocation}

Error message

Could not find symbol for method invocation: {invocation}

What it means

VisitInvocationExpression throws InvalidOperationException when Roslyn's semantic model cannot bind the invoked method to an IMethodSymbol. The translator needs the symbol to map the call to a reflection MethodInfo and emit a MethodCallExpression; without it, translation is impossible.

Source

Thrown at src/EFCore.Design/Query/Internal/CSharpToLinqTranslator.cs:545

                        nameof(FormattableStringFactory.Create), [typeof(string), typeof(object[])])!,

                _ => _stringFormatMethod ??= typeof(string).GetMethod(nameof(string.Format), [typeof(string), typeof(object[])])!
            },
            Constant(formatBuilder.ToString()),
            NewArrayInit(typeof(object), arguments));
    }

    /// <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>
    public override Expression VisitInvocationExpression(InvocationExpressionSyntax invocation)
    {
        if (_semanticModel.GetSymbolInfo(invocation).Symbol is not IMethodSymbol methodSymbol)
        {
            throw new InvalidOperationException("Could not find symbol for method invocation: " + invocation);
        }

        // First, if the method return type is the user's DbContext type (e.g. DbContext local variable, or field/property), return a
        // constant over that DbContext type; the invocation can serve as the root for a LINQ query we can precompile.
        if (methodSymbol.ReturnType.Equals(_userDbContextSymbol, SymbolEqualityComparer.Default))
        {
            return Constant(_userDbContext);
        }

        var declaringType = ResolveType(methodSymbol.ContainingType);

        Expression? instance = null;
        if (!methodSymbol.IsStatic || methodSymbol.IsExtensionMethod)
        {
            // In normal method calls (the ones we support), the invocation node is composed on top of a member access
            if (invocation.Expression is not MemberAccessExpressionSyntax { Expression: var receiver })
            {
                throw new NotSupportedException($"Invocation over non-member access: {invocation}");

View on GitHub (pinned to dbf9771522)

Solutions

Add the missing 'using' directive for the extension method's containing namespace
Ensure the assembly defining the method is referenced by the precompiled-query compilation
Replace dynamic-typed arguments with strongly-typed ones
Inline the helper logic or restrict the query to methods available to the translator

Example fix

// before (helper in unreferenced assembly)
var q = ctx.Blogs.Where(b => MyHelpers.IsActive(b));
// after (method available to the compilation)
var q = ctx.Blogs.Where(b => b.Status == "active");

Defensive patterns

Strategy: validation

Validate before calling

// Ensure the query compiles cleanly and all referenced assemblies are passed to the precompilation.
var compilation = CSharpCompilation.Create(...)
    .AddReferences(MetadataReference.CreateFromFile(typeof(MyHelper).Assembly.Location));
// Verify no 'dynamic' and that all 'using' directives for extension methods are present.

Prevention

Add the 'using' directive for every extension method namespace used in the query
Pass every referenced assembly to the precompiled-query compilation
Avoid dynamic-typed variables inside precompiled queries
Ensure the source has no unrelated compile errors before precompiling

When it happens

Trigger: A method call inside a precompiled query where GetSymbolInfo(invocation).Symbol is not an IMethodSymbol: calls through dynamic, extension methods whose containing namespace/assembly is not referenced by the precompilation, methods on error types, or overload-resolution failures.

Common situations: Missing 'using' for an extension method's namespace; calling a custom helper defined in an assembly not passed to the precompilation; using dynamic-typed variables; invoking a method in source that has other compile errors.

Related errors

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