Add solution-level target framework selection spec - #55647
Conversation
Define nearest-compatible target framework selection for solution and traversal projects, including the direct exact-match requirement for runtime intent. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 230b0c0a-6794-44d3-a17b-d70398d04d7e
|
Azure Pipelines: Successfully started running 1 pipeline(s). 2 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
There was a problem hiding this comment.
Pull request overview
Adds a new design/spec document describing how --framework should behave when the input is a solution/traversal/solution-filter, aligning solution-level selection with project-reference framework negotiation while preserving --framework’s “runtime intent” (requiring at least one direct exact match).
Changes:
- Introduces a proposal spec for solution/traversal
--frameworkbehavior, including nearest-compatible per-direct-project selection and omission rules. - Documents intended CLI/MSBuild property flow (including restore behavior expectations), diagnostics, performance considerations, and test plan.
- Captures integration touchpoints for solution metaproject targets and both
dotnet testpaths (VSTest and Microsoft Testing Platform).
|
|
||
| The `--framework` option currently applies one global `TargetFramework` value to every project in a solution. | ||
|
|
||
| This behavior fails when a project inside the solution does not directly declare the requested framework. The failure is commonly `NETSDK1005`. |
There was a problem hiding this comment.
| This behavior fails when a project inside the solution does not directly declare the requested framework. The failure is commonly `NETSDK1005`. | |
| This behavior fails when any project inside the solution does not directly declare the requested framework. The failure is commonly `NETSDK1005`. |
| | What happens to an incompatible direct project? | The orchestrator omits it and reports it | | ||
| | Can a project build for another framework transitively? | Yes, when a project reference requires it | | ||
| | Does this add a new CLI option? | No | | ||
| | Does explicit `/p:TargetFramework` change? | No | |
There was a problem hiding this comment.
This one I'm not so sure on
| | Can a project build for another framework transitively? | Yes, when a project reference requires it | | ||
| | Does this add a new CLI option? | No | | ||
| | Does explicit `/p:TargetFramework` change? | No | | ||
| | Does solution selection use `AssetTargetFallback`? | No | |
There was a problem hiding this comment.
This gets subtle, right? Like the solution might then not directly reference a specific TF but it might build anyway because of a transitive ref that respects AssetTargetFallback?
There was a problem hiding this comment.
(covered explicitly below but I think it deserves a "not directly" or something rather than the flat "no")
| | Does this add a new CLI option? | No | | ||
| | Does explicit `/p:TargetFramework` change? | No | | ||
| | Does solution selection use `AssetTargetFallback`? | No | | ||
| | Does a container with no direct exact match build? | No | |
There was a problem hiding this comment.
What does "container" here mean? "Solution or traversal project"?
If so, I think we should scope to just "solution" and then update traversal projects to match; we have less direct control there.
|
|
||
| ```text | ||
| Legacy.Tests.csproj TargetFramework=net9.0 | ||
| Portable.Tests.csproj TargetFramework=netstandard2.0 |
There was a problem hiding this comment.
Nit: tests can't target ns2
| Print one summary when some direct entries are incompatible. | ||
|
|
||
| The summary must include each omitted project and its declared target frameworks. |
There was a problem hiding this comment.
Does it have to be one? It might be easier to do one/project to list TFs, and if they have the same code they should be suppressible.
|
|
||
| ## Performance | ||
|
|
||
| Selection adds one `GetTargetFrameworks` request for each direct entry. |
There was a problem hiding this comment.
Worth mentioning that for any referenced project this should be cached (or the later p2p one will be)?
|
|
||
| ## Static graph builds | ||
|
|
||
| Static graph build represents each target-framework configuration as a separate graph node. |
There was a problem hiding this comment.
Sort of! Static graph + multitargeting is a bit of a mess right now. Happy to use this as a forcing factor to work on that . . .
|
|
||
| It rejects compatible projects that a normal project reference can consume. | ||
|
|
||
| This difference preserves the current solution and project inconsistency. |
There was a problem hiding this comment.
I don't think it does? It removes the sln-to-project edges but they can be discovered during ResolveProjectReferences so it still builds successfully, as though you carefully crafted a traversal project pointing to the exact-match leaf nodes?
|
|
||
| 1. Should omitted projects produce a message or a warning during the first release? | ||
| 2. Which `publish` scenarios can safely use project filtering? | ||
| 3. How should solution project metaproject entries participate in selection? |
There was a problem hiding this comment.
Do you mean the metaproject entries that represent solution build order dependencies?
Summary
--frameworkTracks #47093.