[release/10.0] Guard EF file generation against design-time builds to fix AOT build fork bomb

[Copilot]

Fixes #38087

Description
The Microsoft.EntityFrameworkCore.Tasks package wires EF compiled-model / precompiled-query generation into the build via the _EFGenerateFilesAfterBuild target, which is registered in $(TargetsTriggeredByCompilation) and therefore runs after CoreCompile. CoreCompile also runs during Visual Studio design-time builds — the lightweight builds VS/IntelliSense fire continuously while a project is open. Each time the generation target ran it spawned a full, separate out-of-process MSBuild (which in turn invokes the EF design-time generation, loading the runtime and the user assembly). Because design-time builds fire repeatedly and rapidly, these heavyweight spawned builds piled up and consumed all available memory — effectively a fork bomb. Merely opening the project in Visual Studio was enough to trigger it.

The fix adds a '$(DesignTimeBuild)'!='True' condition to the _EFGenerateFilesAfterBuild and _EFGenerateFilesBeforePublish targets so that file generation is skipped during design-time builds and only runs during real builds/publishes, where it belongs. This mirrors the existing pattern already used by the EF NetTopologySuite and HierarchyId targets.

Customer impact
Customers who enable EF's build-time code generation together with Native AOT (the documented combination of EFOptimizeContext and PublishAot/EFScaffoldModelStage/EFPrecompileQueriesStage) have their machine's RAM exhausted as soon as the project is opened in Visual Studio or built, making the feature unusable and the IDE unresponsive. There is no practical workaround other than disabling Native AOT, which defeats the purpose of the feature. Example project settings that trigger it:

<PublishAot>true</PublishAot>
<EFOptimizeContext>true</EFOptimizeContext>
<EFScaffoldModelStage>build</EFScaffoldModelStage>
<EFPrecompileQueriesStage>build</EFPrecompileQueriesStage>

How found
User reported on 10.0.5. The issue has 6 upvotes, indicating multiple affected users.

Regression
Not a regression.

Testing
The Microsoft.EntityFrameworkCore.Tasks build/publish MSBuild integration has no automated test coverage, as it requires real out-of-process MSBuild orchestration including VS-style design-time builds that the test suite does not exercise. Validation was done with a standalone MSBuild repro harness that imports the real targets file and models the SDK compile flow (CoreCompile → $(TargetsTriggeredByCompilation)): with the unguarded targets a design-time build triggers generation (reproducing the bug), while with the guarded targets a design-time build triggers no generation (no spawn, clean exit) and a normal build still generates exactly once and terminates.

Risk
Very low. The change is a two-line MSBuild condition addition to a .targets file that only narrows when generation runs (it never runs during design-time builds, where it should never have run). Normal build and publish generation behavior is unchanged.

[Copilot]

Pull request overview

This PR fixes an out-of-control process spawning scenario (“fork bomb”) caused by EF Core build-time code generation running during Visual Studio design-time builds. It updates the Microsoft.EntityFrameworkCore.Tasks MSBuild integration to skip generation targets when $(DesignTimeBuild) is active, ensuring generation only occurs during real builds/publishes.

Changes:

• Guard _EFGenerateFilesAfterBuild to skip execution during design-time builds.
• Guard _EFGenerateFilesBeforePublish to skip execution during design-time builds.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.