dotnet/efcore · error · InvalidOperationException

Could not resolve type symbol for: {parameter.Type}

Error message

Could not resolve type symbol for: {parameter.Type}

What it means

While translating an anonymous-object initializer, `ResolveType(parameter.Type)` returns null for one of the constructor parameters and the translator throws `InvalidOperationException`. `ResolveType` fails when the Roslyn type symbol cannot be mapped to a CLR `Type` (assembly not loaded / not referenced).

Source

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

        var parameterInfos = new ParameterInfo[parameters.Length];
        var memberInfos = new MemberInfo[parameters.Length];
        var arguments = new Expression[parameters.Length];

        foreach (var initializer in anonymousObjectCreation.Initializers)
        {
            // If the initializer's name isn't explicitly specified, infer it from the initializer's expression like the compiler does
            var name = initializer.NameEquals is not null
                ? initializer.NameEquals.Name.Identifier.Text
                : initializer.Expression is MemberAccessExpressionSyntax memberAccess
                    ? memberAccess.Name.Identifier.Text
                    : throw new InvalidOperationException(
                        $"AnonymousObjectCreation: unnamed initializer with non-MemberAccess expression: {initializer.Expression}");

            var position = Array.FindIndex(parameters, p => p.Name == name);
            var parameter = parameters[position];
            var parameterType = ResolveType(parameter.Type)
                ?? throw new InvalidOperationException(
                    "Could not resolve type symbol for: " + parameter.Type);

            parameterInfos[position] = new FakeParameterInfo(name, parameterType, position);
            arguments[position] = Visit(initializer.Expression);
            memberInfos[position] = anonymousType.GetProperty(parameter.Name)!;
        }

        return New(
            new FakeConstructorInfo(anonymousType, parameterInfos),
            arguments: arguments,
            memberInfos);
    }

    /// <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.

View on GitHub (pinned to dbf9771522)

Solutions

  1. Add a metadata reference for the assembly containing the type to the compilation.
  2. Pass that assembly via the `additionalAssembly` argument of `Load` (used as a fallback in `GetClrTypeFromAssembly`).
  3. Project a type that is already resolvable from the referenced assemblies.

Example fix

// before
translator.Load(compilation, dbContext);   // member type in Other.dll unresolved
// after
translator.Load(compilation, dbContext, additionalAssembly: typeof(OtherType).Assembly);
Defensive patterns

Strategy: validation

Validate before calling

// Pre-resolve all anonymous-member types against the additional assembly.
foreach (var init in anon.Initializers)
{
    var typeInfo = semanticModel.GetTypeInfo(init.Expression).Type;
    if (typeInfo is null
        || (additionalAssembly?.GetType(typeInfo.ToDisplayString()) is null
            && Type.GetType(typeInfo.ToDisplayString()) is null))
        throw new InvalidOperationException(
            $"Projected member type {typeInfo} cannot be resolved; add it to the compilation or additionalAssembly.");
}

Try / catch

try { translator.Translate(node, semanticModel); }
catch (InvalidOperationException ex) when (ex.Message.StartsWith("Could not resolve type symbol for:"))
{ /* add the referenced assembly and retry */ }

Prevention

When it happens

Trigger: An anonymous projection (`new { ... }`) in a precompiled query where one of the projected member's types lives in an assembly that the translator cannot resolve via the compilation or the `additionalAssembly` hint.

Common situations: The entity/value type referenced by the projected member is in a separate assembly not passed as `additionalAssembly`, or the compilation is missing that reference.

Related errors


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