Avoid hardcoded TFMs in source code

[Copilot]

Hardcoded TFMs in shipping .props files and source code require manual updates whenever Arcade bumps TargetFrameworkDefault properties. This eliminates all such hardcodes.

• Retarget to $(NetMinimum): EFCore.Abstractions (was $(DefaultNetCoreTargetFramework)) and EFCore.Tasks (was $(NetCurrent)) now target $(NetMinimum), consistent with ef, dotnet-ef, and EFCore.Tools.

• Stable net / netframework directory names everywhere: All NuGet package layouts now use net and netframework as stable directory prefixes that never need updating, replacing TFM-versioned paths (e.g. net10.0). This applies to:

  • Microsoft.EntityFrameworkCore.Tasks.props — uses net and netframework as _TaskTargetFramework values (plain .props file, no templating needed).
  • EFCore.Tasks.csproj — packs to tasks/net/, tasks/netframework/, tools/net/ with IncludeBuildOutput=false.
  • EFCore.Tools.csproj — packs ef.dll to tools/net/ instead of tools/$(TargetFramework)/any/.
  • dotnet-ef.csproj — packs ef.dll to tools/$(TargetFramework)/any/tools/net/ instead of tools/$(TargetFramework)/any/tools/$(TargetFramework)/any/.

• Simplified OperationTaskBase.cs: Replaced the #if NET472 / #elif guard and dynamic directory discovery with a simple hardcoded "net" path segment.

• Simplified EntityFrameworkCore.psm1: Replaced dynamic Get-ChildItem directory discovery with Join-Path $PSScriptRoot 'net\ef.dll'.

• Simplified dotnet-ef/RootCommand.cs: Replaced the #if !NET10_0 / #error guard and hardcoded "net10.0" path with Path.Combine(toolsPath, "net", "ef.dll").

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Avoid hardcoded TFMs in source-code</issue_title>
<issue_description>https://github.com/search?q=repo%3Adotnet%2Fefcore%20net8.0&type=code

efcore/src/EFCore.Tasks/buildTransitive/Microsoft.EntityFrameworkCore.Tasks.props

Line 5 in e771c0f

<_TaskTargetFramework Condition="'$(MSBuildRuntimeType)' == 'Core'">net10.0</_TaskTargetFramework>

These hardcodes make it harder to update the TFM centrally (i.e. when updating the TargetFrameworkDefault properties in Arcade).

• All the hardcoded TFMs in shipping .props / .targets files can be avoided by changing the "tools//" package paths to "tools/net/" and "tools/netframework/". The TFM version doesn't provide value there. We already do this in arcade, sourcelink and will likely soon in sdk as well.

This is in reaction to dotnet/dotnet@985a8fe which we had to do in the VMR when updated the TFM properties.</issue_description>

<agent_instructions>Also, .Abstractions and .Tasks projects should target NetMinimum</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@AndriySvyryd Also, `.Abstractions` and `.Tasks` should target `NetMinimum`

• Fixes Avoid hardcoded TFMs in source-code #37473

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR removes hardcoded Target Framework Monikers (TFMs) from shipped .props files and tool/task path discovery, so Arcade TFM bumps don’t require source/package layout updates across EF Core tooling.

Changes:

• Standardizes NuGet package layouts to use stable net/ and netframework/ directory prefixes (instead of TFM-versioned directories).
• Retargets EFCore.Abstractions and EFCore.Tasks to $(NetMinimum) for consistency with other tooling projects.
• Simplifies runtime path resolution in dotnet-ef, EFCore.Tasks, and PMC tooling to load ef.dll from stable net/ paths.

Reviewed changes

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

Show a summary per file

File	Description
src/dotnet-ef/dotnet-ef.csproj	Packs ef.dll under a stable tools/.../tools/net folder inside the dotnet tool layout.
src/dotnet-ef/RootCommand.cs	Loads ef.dll from tools/net/ef.dll instead of a hardcoded TFM directory.
src/EFCore.Tools/tools/EntityFrameworkCore.psm1	Updates PMC tooling to execute ef.dll from tools\net\ef.dll.
src/EFCore.Tools/EFCore.Tools.csproj	Packs ef.dll into tools/net/ to match the updated PMC script lookup.
src/EFCore.Tasks/buildTransitive/Microsoft.EntityFrameworkCore.Tasks.props	Uses stable net/netframework folder names when locating task assemblies.
src/EFCore.Tasks/Tasks/Internal/OperationTaskBase.cs	Simplifies ef.dll resolution to tools/net/ef.dll based on package root.
src/EFCore.Tasks/EFCore.Tasks.csproj	Retargets to $(NetMinimum) and updates packing to stable tasks/net, tasks/netframework, and tools/net.
src/EFCore.Abstractions/EFCore.Abstractions.csproj	Retargets to $(NetMinimum) to avoid hardcoding default framework properties.

---

You can also share your feedback on Copilot code review. Take the survey.

[ViktorHofer]

I understand the reason for this change but this will cause the pdb to be omitted from the symbols package. We should chat with NuGet on how to correctly include the symbols in that scenario.

https://github.com/NuGet/NuGet.Client/blob/8deb76a20811f7b78531b66a1024cfe9e650cc69/src/NuGet.Core/NuGet.Build.Tasks/NuGet.Build.Tasks.Pack.targets#L382-L384

[ViktorHofer]

@zivkan are you the right contact for NuGet Pack questions? We are using TfmSpecificDebugSymbolsFile in L86 to include a pdb into the symbols package. That works well but now this PR changes the IncludeBuildOutput flag to false which makes the item not getting respected anymore (see link above). Can you please share guidance on how to do this "the right way"?

[zivkan]

Unfortunately, Pack hasn't had much investment since I joined the team, so I've never had the opportunity to learn the breadth of features or common problems and solution. I'm also confident that the only "friendly" helper is pack as tool for .NET tools, but we need to make improvements for packing msbuild task packages, as well as roslyn analyzers. It's a gap.

Down on line 76, I see a pdb is being added via TfmSpecificPackageFile. I would have hoped that NuGet's existing logic to split the symbols package would make this work automatically. Can we check the CI build artifacts? If it doesn't work, there's another target that includes TfmSpecificDebugSymbolsFile: https://github.com/NuGet/NuGet.Client/blob/8deb76a20811f7b78531b66a1024cfe9e650cc69/src/NuGet.Core/NuGet.Build.Tasks/NuGet.Build.Tasks.Pack.targets#L471

[AndriySvyryd]

Filed dotnet/sdk#53313