osprey: Pin LangVersion to 14, which the tree already requires

[maccoss]

What changed since the first version of this PR

The original premise was wrong, and Brendan was right to push back: master is not
broken. It builds and tests green on TeamCity, in VS 2026, and on his machine. The
failure was mine, from building with the .NET 9 SDK.

This PR is now a one-property change that makes the real requirement explicit.

Diagnosis

Osprey.Scoring/PickLdaModel.cs validates a pick model's feature list:

if (dto.Features == null || dto.Features.Length != N ||
    !dto.Features.SequenceEqual(ExpectedFeatures))

Both operands are string[], and the file imports System but not System.Linq.

• Under C# 14, string[] implicitly converts to ReadOnlySpan<string> in extension
  receiver position (the "first-class span types" feature), so this binds to
  System.MemoryExtensions.SequenceEqual, already covered by using System;. Adding
  using System.Linq; is redundant, which is why ReSharper flags it.
• Under C# 13 and earlier, that conversion does not exist. The only candidate is
  System.Linq.Enumerable.SequenceEqual, which the file does not import, so it fails.

So Osprey has required C# 14, and therefore the .NET 10 SDK, since dd9e845 introduced
the file. <LangVersion>latest</LangVersion> concealed that: it means "whatever this SDK
supports", so the requirement was never stated and never checked.

Reproduced both directions on a clean origin/master worktree, no other change:

SDK	latest resolves to	Result
10.0.400	C# 14	builds clean, net472 and net8.0
9.0.315	C# 13	CS1061: 'string[]' does not contain a definition for 'SequenceEqual'

The diagnostic is the real problem here. It points at source that looks correct and says
nothing about language versions, so it reads as "master is broken" rather than "your SDK
is too old". That is exactly the wrong conclusion to hand a new contributor, or an agent.

The change

pwiz_tools/Osprey/Directory.Build.props: <LangVersion>latest</LangVersion> becomes
<LangVersion>14</LangVersion>, with a comment recording what requires it.

Now an SDK that cannot build Osprey says so directly:

error CS1617: Invalid option '14' for /langversion. Use '/langversion:?' to list supported values.

This also matches how the rest of the tree declares it. pwiz_tools/Directory.Build.props
pins 8.0; CommonFileDialogs, CommonMsData, PanoramaClient and BullseyeSharp pin
8.0 or 7.3. Osprey was the outlier in tracking whatever SDK was installed.

I have upgraded to the .NET 10.0.400 SDK, and everything below was re-verified on it.

Verification

• .NET 10.0.400 SDK: Osprey.sln builds clean, 0 warnings, 0 errors
• .NET 10.0.400 SDK: Osprey.Test 586/586 on net8.0, 586/586 on net472
• .NET 9.0.315 SDK: build stops at CS1617, naming the actual cause

Not done here, worth deciding separately

• A repo-root global.json would state the SDK floor once instead of leaving each project
  to imply it through LangVersion. That is a repo-wide call, not an Osprey one.
• The other <LangVersion>latest</LangVersion> users (PortableUtil, the DevTools
  projects) may have picked up C# 13/14 dependencies the same way, without anyone
  choosing to. Worth an audit.

#4595 is stacked on this branch and has been rebased onto it.

See ai/todos/active/TODO-20260820_osprey_scoring_linq_build_fix.md.

[Copilot]

Pull request overview

Fixes a build break in pwiz_tools/Osprey/Osprey.Scoring by restoring the missing LINQ import needed for SequenceEqual on string[] in PickLdaModel.LoadFromFile.

Changes:

• Add using System.Linq; to enable dto.Features.SequenceEqual(ExpectedFeatures) to compile.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[maccoss]

Brendan is right - this was my machine, not master. I was building with the .NET 9 SDK.

Root cause, reproduced on a clean origin/master worktree with no other change: the
string[].SequenceEqual(string[]) call in PickLdaModel.cs binds to
System.MemoryExtensions.SequenceEqual under C# 14, through the first-class-spans
implicit conversion in extension receiver position, so using System; is enough. Under
C# 13 the only candidate is Enumerable.SequenceEqual and the file does not import
System.Linq, so it fails. SDK 10.0.400 builds it; SDK 9.0.315 gives CS1061.

That also explains the ReSharper warning - the using genuinely is redundant on your
toolchain, so adding it was the wrong fix.

I have dropped the using and repurposed this PR to pin <LangVersion>14</LangVersion> in
pwiz_tools/Osprey/Directory.Build.props, per Mike's suggestion. Osprey has required C# 14
since dd9e845; latest just meant nobody had to say so. With the pin, an old SDK fails
as CS1617: Invalid option '14' for /langversion instead of pointing at a line of source
that looks fine.

Re-verified on SDK 10.0.400: Osprey.sln clean, Osprey.Test 586/586 on net472 and
net8.0. #4595 has been rebased onto this.

Two things I did not do, in the PR description: a repo-root global.json, and an audit of
the other LangVersion=latest projects (PortableUtil, DevTools), which may have picked
up the same undeclared dependency.

Sorry for the noise - the branch name still says "linq_build_fix", which no longer
describes it. Happy to move this to a correctly named branch if you would rather.

[maccoss]

Closing this - not needed.

The build requirement is already VS 2026 and the .NET 10 SDK, so latest resolves to C# 14
on every supported toolchain and pinning it declares nothing the team does not already
guarantee. The original failure was my machine running the .NET 9 SDK; I have upgraded to
10.0.400.

#4595 has been rebased off this branch and now targets master directly, so nothing
depends on it. Re-verified standalone on master with SDK 10.0.400: Osprey.sln builds
clean, Osprey.Test 589/589 on net472 and net8.0, and the gradient boosted trees remain
bit-identical to master's on the logistic path.

Recording the diagnosis here since it cost some time and will cost the next person the
same: Osprey.Scoring/PickLdaModel.cs calls string[].SequenceEqual(string[]) with only
using System; imported. Under C# 14 that binds to System.MemoryExtensions.SequenceEqual
via the first-class-spans implicit conversion in extension receiver position. Under C# 13
the only candidate is System.Linq.Enumerable.SequenceEqual, which the file does not
import, so an older SDK fails with

CS1061: 'string[]' does not contain a definition for 'SequenceEqual'

on a line that looks perfectly fine, naming neither the SDK nor the language version. So
Osprey has required C# 14 since dd9e845. Master is fine; the diagnostic is just
misleading if you show up with the wrong SDK.

Thanks Brendan for pushing back rather than letting the wrong fix through.