Skip to content

ci(inspectcode): move to windows-latest to resolve .NET Framework references - #248

Merged
Chris-Wolfgang merged 3 commits into
mainfrom
fix/inspectcode-runs-on-windows
Jul 14, 2026
Merged

ci(inspectcode): move to windows-latest to resolve .NET Framework references#248
Chris-Wolfgang merged 3 commits into
mainfrom
fix/inspectcode-runs-on-windows

Conversation

@Chris-Wolfgang

Copy link
Copy Markdown
Owner

Summary

Move the ReSharper InspectCode job from ubuntu-latest to windows-latest. Try-Pattern ships .NET Framework 4.6.2 example projects (C#, VB, F#) and jb inspectcode walks the full solution — on Linux without mono, the Framework reference assemblies (System, System.Xml.Linq, System.Data.DataSetExtensions, etc.) can't be resolved, and InspectCode emits 60 MSB3245 assembly-resolution errors as error-severity findings per run, failing the gate.

Windows has those reference assemblies bundled at C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2\, so references resolve natively without needing mono or a build step.

Observed on PR #247's run: FAILURE with 60 findings, all Framework-example assembly-resolution errors. The version-picker.js change itself is fine — this is a pre-existing pr.yaml issue that landed with #245 and would fire on any PR.

Changes

  • runs-on: ubuntu-latestruns-on: windows-latest
  • Pin defaults.run.shell: bash at the job level. All the run scripts use bash-only syntax (while IFS= read -r -d '', ${arr[@]}, <() process substitution, [[ ]]). Windows runners default to pwsh; without the pin, the scripts would break. Git for Windows provides bash on windows-latest.
  • Header comment updated to document the rationale.

Why not other options considered

Option Why not
--target-framework=net10.0 on jb inspectcode Skips analyzing Framework-example source entirely, so real analyzer findings there go undetected
Install mono on ubuntu-latest Adds ~20s per run, another moving part; solves the same problem more expensively than just running on Windows
Add --project include-list Fragile — a new project sneaks past the filter and the fleet-shared workflow shape drifts

Test plan

  • YAML parses (verified via Python + pyyaml locally)
  • CI runs on Windows and finds 0 error-severity findings (already verified with jb inspectcode locally where the same Windows-native reference-assembly resolution applies)
  • Wall-clock impact ≤ Stage 2 Windows Tests

Protected file

This PR only touches .github/workflows/pr.yaml. Detect .NET Projects will fail as expected → admin-bypass required per protected-file-pr-split.

Fleet impact

Fleet-rollout memory noted windows-latest for net4x-ONLY repos. This case (mixed multi-TFM + Framework-only-example) is the more common shape and also needs Windows. Applies to at least: DateTime-Extensions, IEnumerable-Extensions, IAsyncEnumerable-Extensions, and probably every other extensions repo with example projects. Fold into the 20 open chore/add-inspectcode fleet PRs before they land.

…erences

Try-Pattern ships .NET Framework 4.6.2 example projects (C#, VB, F#).
On the previous ubuntu-latest InspectCode runner, `jb inspectcode` walks
the full solution and tries to resolve their assembly references —
System, System.Xml.Linq, System.Data.DataSetExtensions, etc. — which
aren't present without mono installed. Result: 60 MSB3245
assembly-resolution errors per run, all emitted as InspectCode
error-severity findings that fail the gate.

Fix: run InspectCode on windows-latest instead. Windows has the .NET
Framework reference assemblies bundled at
`C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2\`
so the references resolve natively without a build step. The
build-time exclusion loop below still works — bash on windows-latest
via Git for Windows is byte-compatible with the ubuntu one — but is
now redundant for the InspectCode-side; keeping it for now since it
doesn't add wall-clock.

Also pins `defaults.run.shell: bash` at the job level so future runner
swaps don't accidentally hit windows-latest's pwsh default and break
the process-substitution / [[]] / `${arr[@]}` syntax in the run
scripts below.

The build + test stages parallelize this on Linux/Windows/macOS in
Stage 1/2/3, so moving InspectCode to Windows doesn't add to the
wall-clock the way an extra dedicated test stage would.

Follow-up (out of scope): the "Restore and build (exclude .NET
Framework-only projects)" step's exclusion loop is now cosmetic —
Windows can build the Framework projects natively. Simplifying it is
future work.
Copilot AI review requested due to automatic review settings July 14, 2026 00:46

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the PR CI workflow to run the ReSharper InspectCode job on a Windows runner so that .NET Framework reference assemblies resolve without needing mono, and ensures the job’s bash-based scripts still run correctly on Windows.

Changes:

  • Move inspectcode from ubuntu-latest to windows-latest to avoid net4x reference-assembly resolution failures.
  • Set job-level defaults.run.shell: bash to keep existing bash-specific scripts working on Windows runners.
  • Add inline documentation explaining the rationale for the runner/shell changes.

Comment thread .github/workflows/pr.yaml
Comment thread .github/workflows/pr.yaml
Two Copilot findings on #248:

1. Gate step used `jq` — preinstalled on ubuntu-latest but not
   guaranteed on windows-latest. Rewrote to `shell: pwsh` +
   ConvertFrom-Json so the step doesn't depend on any preinstalled
   utility beyond PowerShell (native on windows-latest).

2. "Restore and build (exclude .NET Framework-only projects)" step
   still framed net4x projects as "incompatible with Linux" and
   filtered them out — a leftover from the ubuntu-latest era.
   Now that we're on windows-latest with the Framework reference
   assemblies bundled, we can just `dotnet restore && dotnet build`
   at the root and let all projects (including net462 examples) build
   natively. Dropped the filter loop; renamed step to
   "Restore and build".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants