dotnet/efcore · error · InvalidOperationException

Could not find type symbol for: {fullyQualifiedMetadataName}

Error message

Could not find type symbol for: {fullyQualifiedMetadataName}

What it means

`CSharpToLinqTranslator.Load` calls the local `GetTypeSymbolOrThrow`, which does `_compilation.GetTypeByMetadataName(fullyQualifiedMetadataName)` and throws `InvalidOperationException` if it returns null. It is invoked for the user's DbContext type (`userDbContext.GetType().FullName`) and for `System.FormattableString`, so the compilation passed to `Load` must be able to resolve both.

Source

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

    /// <param name="userDbContext">An instance of the user's <see cref="DbContext" />.</param>
    /// <param name="additionalAssembly">An optional additional assemblies to resolve CLR types from.</param>
    /// <remarks>
    ///     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.
    /// </remarks>
    public virtual void Load(Compilation compilation, DbContext userDbContext, Assembly? additionalAssembly = null)
    {
        _compilation = compilation;
        _userDbContext = userDbContext;
        _additionalAssembly = additionalAssembly;
        _userDbContextSymbol = GetTypeSymbolOrThrow(userDbContext.GetType().FullName!);
        _formattableStringSymbol = GetTypeSymbolOrThrow("System.FormattableString");

        INamedTypeSymbol GetTypeSymbolOrThrow(string fullyQualifiedMetadataName)
            => _compilation.GetTypeByMetadataName(fullyQualifiedMetadataName)
                ?? throw new InvalidOperationException("Could not find type symbol for: " + fullyQualifiedMetadataName);
    }

    private readonly Stack<ImmutableDictionary<string, ParameterExpression>> _parameterStack
        = new([ImmutableDictionary<string, ParameterExpression>.Empty]);

    private readonly Dictionary<ISymbol, MemberExpression?> _dataFlowsIn = [with(SymbolEqualityComparer.Default)];

    /// <summary>
    ///     Translates a Roslyn syntax tree into a LINQ expression tree.
    /// </summary>
    /// <param name="node">The Roslyn syntax node to be translated.</param>
    /// <param name="semanticModel">
    ///     The <see cref="SemanticModel" /> for the Roslyn <see cref="SyntaxTree" /> of which <paramref name="node" /> is a part.
    /// </param>
    /// <returns>A LINQ expression tree translated from the provided <paramref name="node" />.</returns>
    /// <remarks>
    ///     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

View on GitHub (pinned to dbf9771522)

Solutions

  1. Add the DbContext's assembly as a metadata reference to the compilation before calling `Load`.
  2. Ensure the compilation also references the core library that defines `System.FormattableString` (e.g. `typeof(FormattableString).Assembly`).
  3. If the DbContext lives in a test ALC, pass that assembly via the `additionalAssembly` parameter.

Example fix

// before
var compilation = CSharpCompilation.Create("q").AddSyntaxTrees(tree);
translator.Load(compilation, dbContext);
// after
var compilation = CSharpCompilation.Create("q")
    .AddSyntaxTrees(tree)
    .AddReferences(
        MetadataReference.CreateFromFile(dbContext.GetType().Assembly.Location),
        MetadataReference.CreateFromFile(typeof(FormattableString).Assembly.Location));
translator.Load(compilation, dbContext);
Defensive patterns

Strategy: validation

Validate before calling

// Verify the compilation can resolve the DbContext and FormattableString before Load.
static void EnsureReferences(CSharpCompilation compilation, Type dbContextType)
{
    if (compilation.GetTypeByMetadataName(dbContextType.FullName!) is null)
        throw new InvalidOperationException(
            $"Compilation is missing a reference to the assembly defining {dbContextType.FullName}.");
    if (compilation.GetTypeByMetadataName("System.FormattableString") is null)
        throw new InvalidOperationException(
            "Compilation is missing a reference to the core library (System.FormattableString).");
}

EnsureReferences(compilation, typeof(MyContext));
translator.Load(compilation, dbContext);

Try / catch

// Wrap Load in a try/catch focused on the type-symbol resolution failure.
try
{
    translator.Load(compilation, dbContext, additionalAssembly);
}
catch (InvalidOperationException ex) when (ex.Message.StartsWith("Could not find type symbol for:"))
{
    // Add the missing metadata reference and retry, or report a clear config error.
    throw new InvalidOperationException(
        "The Roslyn compilation cannot resolve a required type. " +
        "Add MetadataReferences for the DbContext assembly and the BCL.", ex);
}

Prevention

When it happens

Trigger: Calling `translator.Load(compilation, userDbContext, additionalAssembly)` with a Roslyn `Compilation` that has no metadata reference to the assembly defining the DbContext (or to the core library that defines `System.FormattableString`). This path is exercised by EF Core's precompiled-query pipeline.

Common situations: Building the `Compilation` without adding `MetadataReference.CreateFromFile(typeof(MyContext).Assembly.Location)`, targeting a TFM whose core assembly differs, or passing a `Compilation` assembled from the wrong syntax trees.

Related errors


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