Name Each Root Workspace Where the Root Holds More Than One .NET Solution or Project #3795

Activity

1. ptr727

   added

   pre-existingReview finding classed pre-existing per local-strict-review Disposing of FindingsReview finding classed pre-existing per local-strict-review Disposing of Findings

   on Nov 1, 2026
2. ptr727

   added a commit that references this issue on Nov 2, 2026

   Gate the Required Check Name, Latest Flag, Lint Interpreter, and .NET…

   ...

   9e06417
3. ptr727 commented on Nov 2, 2026

   

   ptr727

   on Nov 2, 2026

   OwnerAuthor

   More actions

   Decision triage: researched question

   Where the repository root holds more than one .NET solution or project, should validate-task.yml name each one, or choose one by a stated rule, and which rule?

   Options, recommended first:

   1. (Recommended) Keep the bare call only where the root holds exactly one workspace, and otherwise use the validate-task Runs dotnet format at the Root Where No Project or Solution Sits There #1938 naming rule. This reuses the rule already chosen on validate-task Runs dotnet format at the Root Where No Project or Solution Sits There #1938 (each tracked solution for style, each *Tests*.csproj by --project for tests), so no new rule is needed. The test step names projects rather than solutions, so an App.sln left beside App.slnx never runs tests twice. WORKFLOW.md D1.6's "root holds no solution or project" wording changes with it. The change fits best in the single resolver Resolve .NET Workspaces Once in a validate-task Composite Action #3791 proposes. Until Resolve .NET Workspaces Once in a validate-task Composite Action #3791 lands, both resolver copies change together because of the identity test.
   2. Choose one root workspace by a stated precedence (.slnx, then .sln, then .csproj, then first by name). Handles the dotnet sln migrate leftover in one run. Where the root holds two distinct solutions, or a solution beside a project it does not list, the rest is skipped silently, a false clean.
   3. Fail with an explicit error naming the root files. Cheapest change, and the caller fixes the layout. It turns a layout dotnet accepts when given an argument into a gate failure, against the "no caller change" direction of the validate-task Runs dotnet format at the Root Where No Project or Solution Sits There #1938 answer.
   4. Leave it and record the limit. No registered C# repo hits it today, since each tracks exactly one root .slnx. The first adopter with such a root gets MSB1011 on both steps.

   Evidence: .github/workflows/validate-task.yml:290-318 and :659-689 on main (dotnet_workspaces, bare call whenever any root .sln/.slnx/.csproj is tracked); WORKFLOW.md:146 (D1.6 states only the root-none rule); #1938 answer #1938 (comment); #3796 (merged, 9e06417); tests/test_release_guards.py:2027 (identity test over the two resolver copies); #3791 (proposed single composite resolver).

   In flight: #3791 and the #1270/#1259 test-project-signal change both touch the same resolver and the *Tests*.csproj glob, so these land through #3791 or in sequence after it.
4. ptr727

   added

   decisionA question waiting on the maintainer, alone or beside whatever else the issue carriesA question waiting on the maintainer, alone or beside whatever else the issue carries

   on Nov 2, 2026
5. ptr727 commented on Nov 2, 2026

   

   ptr727

   on Nov 2, 2026

   OwnerAuthor

   More actions

   Maintainer answer (2026-11-02, via decision triage): reuse the #1938 naming rule.

   Keep the bare call only where the root holds exactly one workspace. Otherwise name each tracked solution for the style step and each *Tests*.csproj by --project for the test step. Update the WORKFLOW.md D1.6 wording with it. Land it through the #3791 single resolver or in sequence after it, coordinated with the #1270/#1259 test-project-signal change. This issue stays open as work.
6. ptr727

   removed

   decisionA question waiting on the maintainer, alone or beside whatever else the issue carriesA question waiting on the maintainer, alone or beside whatever else the issue carries

   on Nov 2, 2026