dotnet ef dbcontext optimize --precompile-queries does not pass $(Configuration) to MSBuildWorkspace, breaking non-default build configurations

[ncipollina]

Environment

• .NET SDK: 11.0.100-rc.1.26425.128
• Also reproduces on .NET 10 SDKs with EF Core 10.0.12
• EF Core: 10.0.12 and 11.0.0-rc.1.26425.128
• OS: macOS arm64
• This appears to be MSBuild/Roslyn-level behavior and not OS-specific

Reproduction

A minimal project uses a non-default $(Configuration) name with Configuration-conditional TargetFramework and PackageReference values.

For example:

<TargetFramework>net10.0</TargetFramework>

<Configurations>Debug Custom;Release Custom</Configurations>

<PropertyGroup Condition="'$(Configuration)' == 'Debug Custom' Or '$(Configuration)' == 'Release Custom'">
  <TargetFramework>net11.0</TargetFramework>
</PropertyGroup>

EF Core package references are conditioned on the resulting target framework.

Run:

dotnet publish MyProj.csproj --configuration "Release Custom"

The normal build succeeds correctly under Release Custom, producing the expected net11.0 output with the correct EF Core version.

The OptimizeDbContext task then invokes:

dotnet ef dbcontext optimize --precompile-queries --nativeaot

against the already-built application.

That query-precompilation step fails with errors such as:

error CS0234: The type or namespace name 'EntityFrameworkCore' does not exist in the namespace 'Microsoft'

error CS0246: The type or namespace name 'DbContext' could not be found

followed by cascading resolution errors across the project.

Expected behavior

The project reopened by MSBuildWorkspace during query precompilation should be evaluated with the same relevant MSBuild global properties as the build that invoked OptimizeDbContext.

At minimum, the active $(Configuration) should be preserved.

Actual behavior

DbContextOperations.PrecompileQueries creates the workspace with only:

workspace = MSBuildWorkspace.Create(
    new Dictionary<string, string>
    {
        ["_EFGenerationStage"] = "build"
    });

There is also an adjacent:

// TODO: pass through properties

comment.

OpenProjectAsync then re-evaluates the actual .csproj, but without the active Configuration.

For projects whose target framework, package references, project references, or other build properties depend on $(Configuration), that re-evaluation can resolve an entirely different project graph than the build currently in progress.

In the minimal repro, the workspace falls back to the project's unconditional/default target framework and package set rather than the Release Custom graph that was successfully built moments earlier.

The generated-query compilation therefore cannot resolve the application's EF Core references and fails.

Root cause

The issue appears to originate in:

src/EFCore.Design/Design/Internal/DbContextOperations.cs

inside PrecompileQueries, specifically the MSBuildWorkspace.Create(...) call.

The relevant implementation, including the // TODO: pass through properties comment, is unchanged in:

• EF Core 10.0.12
• EF Core 11.0.0-rc.1.26425.128

Impact

This blocks Native AOT / precompiled-query publishing for projects using legitimate non-default build configuration names or Configuration-conditioned dependencies.

This is not provider-specific.

I encountered it while enabling EF Core 11 Native AOT support for a third-party provider which intentionally maintains separate builds using:

Debug EF10
Release EF10
Debug EF11
Release EF11

The same problem was then reproduced in a standalone project with no third-party provider code.

Minimal repro

The repro consists of a single project and Program.cs. Two variants were tested:

• EF Core 11 RC1 with an unconditional net10.0 default overridden to net11.0 by Release Custom
• EF Core 10.0.12 with the target frameworks reversed

Both reproduce the same failure.

The query-free DbContext is intentional so that this issue remains isolated from unrelated query-translation/precompilation behavior.

I can provide the minimal repro if useful.

Versions

Confirmed affected:

• Microsoft.EntityFrameworkCore.Design / Tasks 10.0.12
• Microsoft.EntityFrameworkCore.Design / Tasks 11.0.0-rc.1.26425.128

Possibly related

#36055 hits the same DbContextOperations.PrecompileQueries → MSBuildWorkspace.OpenProjectAsync code path with a different proximate symptom ("The build host could not be found"). Flagging in case the two share a root cause in how MSBuildWorkspace is used here, though the specific defect described above (missing Configuration passthrough) is distinct from that report.