Update .NET target from net8.0 to net10.0

[imnasnainaec]

.NET 8 reaches end of support on 2026-11-10. .NET 10 is the current LTS (supported through
November 2028). We need net10.0/net10.0-windows coverage for our modern target frameworks.

This assumes #161 has landed, so the .NET Framework targets are already net462;net48 and
System.Resources.Extensions / SIL.ReleaseTasks / System.ServiceModel.* are already on
current versions. The .NET Framework and netstandard2.0 targets are unaffected by this issue.

Decision needed first

Do we replace net8.0 or add net10.0 alongside it? Both are on the table; see the consumer
survey in the comments for what each costs downstream.

• Replace: simplest, but it is a breaking change —
  L10NSharp.Windows.Forms, L10NSharp.CheckOrFixXliff and L10NSharp.ExtractXliff would no
  longer have assets that apply to a net8.0/net9.0 consumer. Requires +semver:major
  (see the Semantic Versioning section of the README).
• Add alongside (net8.0;net10.0): non-breaking (+semver:minor), at the cost of a longer
  build matrix, until .NET 8 goes out of support in November 2026.

Note that the L10NSharp core package itself targets netstandard2.0 (not net8.0), so it is
unaffected either way; only the three packages listed above and the test/sample projects carry a
net8.0* TFM.

Changes required

The sites are the same either way — the decision above only settles whether each net8.0* TFM is
replaced by its net10.0* counterpart or joined by it.

Target frameworks:

• src/CheckOrFixXliff/CheckOrFixXliff.csproj:5 — $(TargetFrameworks);net8.0 → net10.0
• src/ExtractXliff/ExtractXliff.csproj:5 — $(TargetFrameworks);net8.0 → net10.0
• src/L10NSharp.Tests/L10NSharp.Tests.csproj:3 — $(TargetFrameworks);net8.0 → net10.0
• src/L10NSharp.Windows.Forms/L10NSharp.Windows.Forms.csproj:4 — net8.0-windows → net10.0-windows
• src/L10NSharp.Windows.Forms/L10NSharp.Windows.Forms.csproj:15 — the
  '$(TargetFramework)' == 'net8.0-windows' condition guarding the System.ServiceModel.*
  package references
• src/L10NSharp.Windows.Forms.Tests/L10NSharp.Windows.Forms.Tests.csproj:3 — net8.0-windows → net10.0-windows
• src/SampleApp/SampleApp.csproj:3 — net8.0-windows → net10.0-windows

CI:

• .github/workflows/CI-CD.yml:37 — dotnet-version: 8.0.x → 10.0.x
• .github/workflows/CI-CD.yml:51 — the Linux test step's --framework net8.0 → net10.0.
  This is the only step that runs on Ubuntu, so it is our sole cross-platform coverage; it must
  keep working.
• Confirm the windows-latest and ubuntu-latest runner images ship (or setup-dotnet
  installs) a .NET 10 SDK, and that Autobuild in .github/workflows/codeql.yml still resolves
  an SDK that can build the new TFMs.

Docs:

• CHANGELOG.md entry under [Unreleased] (### Changed, marked BREAKING CHANGE if we drop
  net8.0), and the +semver:major (or :minor) marker on the commit.

Likely follow-on work / risks

These are the parts most likely to turn a one-line TFM bump into real work:

• GitVersion.MsBuild 5.11.1 (all packable projects) predates the .NET 10 SDK and may not load
  under it. Moving to GitVersion 6.x means migrating GitVersion.yml, which still uses the v5
  schema (mode: ContinuousDeployment, tag: on each branch — renamed to label: in v6, with
  changed ContinuousDeployment semantics). Getting version numbers wrong here affects what gets
  published to nuget.org, so this deserves care.
• Test tooling is from 2022: Microsoft.NET.Test.Sdk 17.4.0, NUnit 3.13.3,
  NUnit3TestAdapter 4.3.2. These are likely to need bumping to run on a .NET 10 SDK / VSTest.
  Note that .github/workflows/CI-CD.yml invokes dotnet test against pre-built DLLs
  (--no-build output\Release\net462\*Tests.dll), so adapter/runner changes can break CI in ways
  a local dotnet test will not show.
• System.ServiceModel.Http / System.ServiceModel.Primitives 8.1.2 — check for a version
  aligned with .NET 10 and re-verify the BingTranslator / generated WCF proxy code, which Upgrade SIL.ReleaseTasks and System.ServiceModel dependencies; replace net461 with net462 #161
  already had to adjust for API removals. (Related: BingTranslator API has been retired #163 — the Bing API itself is retired, so this
  code may be on its way out regardless.)
• Microsoft.SourceLink.GitHub 1.1.1 is redundant on .NET 8+ SDKs (SourceLink is built in).
  Harmless, but a good opportunity to drop it if it causes friction.
• LangVersion is pinned to 8.0 in Directory.Build.props for all TFMs. Not required to
  change, but if we want newer C# on the modern target only, this is where it would happen.
  Out of scope unless something forces it.

Verification

• dotnet build L10NSharp.sln clean across net462, net48, netstandard2.0, net10.0,
  net10.0-windows (plus net8.0* if retained)
• dotnet test passes on Windows (all TFMs) and on Linux (--framework net10.0)
• SampleApp.exe launches for net462, net48, and net10.0-windows
• Generated .nupkgs contain the expected lib/ folders and the version number is what
  GitVersion produced before the change (i.e. no accidental version regression)

---

Drafted by Claude Opus 5 (1M context) (claude-opus-5[1m]) via Claude Code.

[imnasnainaec]

Impact on sillsdev consumers

I surveyed the sillsdev org (GitHub code search over public repos' default branches, so private
repos and feature branches aren't covered). Short version: only libpalaso is actually broken by
dropping net8.0, and it is the one that gates everyone else.

The reason the blast radius is small is that the core L10NSharp package has no net8.0 target at
all — it is net462;net48;netstandard2.0. Only L10NSharp.Windows.Forms (net8.0-windows) and the
two tool packages (net8.0) carry a modern TFM.

Blocked: libpalaso

Project	TFMs	L10NSharp reference
SIL.Windows.Forms	net462;net48;net8.0-windows	L10NSharp + L10NSharp.Windows.Forms 10.0.0-beta0004
SIL.Windows.Forms.Keyboarding	net462;net48;net8.0-windows	L10NSharp + L10NSharp.Windows.Forms 10.0.0-beta0004
SIL.Core.Desktop	net462;net48;netstandard2.0	L10NSharp 10.0.0-beta0004 — unaffected

If L10NSharp.Windows.Forms drops net8.0-windows, those two libpalaso projects have no compatible
asset and restore fails (NU1202). libpalaso's .github/workflows/build.yml also hard-codes the
matrix [net462, net48, net8.0, net8.0-windows] and does its packing/publishing from the
net8.0-windows job, so this is a coordinated change, not a one-liner on their side.

This matters out of proportion to the single repo: FieldWorks, Glyssen, chorus, hearthis, SayMore and
the rest consume L10NSharp through the SIL.* packages, so libpalaso has to move before any of
them can.

Unaffected: everything else

Every other sillsdev consumer is .NET Framework or netstandard2.0 only, and several are pinned to
much older L10NSharp versions:

Repo	TFM	L10NSharp
chorus (LibChorus)	net462;netstandard2.0	10.0.0-*
FieldWorks	net48	central package management (<PackageReference Include="L10NSharp" />)
Glyssen	v4.7.2 (old-style csproj)	PackageReference
Transcelerator	v4.8	8.0.0, via HintPath to packages\L10NSharp.8.0.0\lib\net48\
hearthis	net472	8.0.0
SayMore	net48	8.0.0
WeSay	v4.6.1	5.0.0-beta0086, lib\net461\
chono, pathway, phonology-assistant, solid	.NET Framework	dormant (last pushed 2022–2025)

The ExtractXliff tool is a separate, quieter story

libpalaso, chorus, Glyssen, Transcelerator, hearthis, chono and flexbridge all shell out to
ExtractXliff.exe from their l10n/l10n.proj:

<PackageReference Include="L10NSharp.ExtractXliff" Version="7.0.0-beta0011" GeneratePathProperty="true" />
...
<Exec Command="&quot;$(PkgL10NSharp_ExtractXliff)\tools\ExtractXliff.exe&quot; ..." />

They invoke the .NET Framework executable out of the package's tools/ folder and are pinned to
7.0.0-beta0011, so changing the tool's modern TFM doesn't touch them today. The thing to watch is
that these l10n workflows install dotnet-version: 8.x (e.g. libpalaso's l10n-source.yml); if any
of them ever moves to a build of L10NSharp.ExtractXliff whose only modern target is net10.0,
those runners need a .NET 10 SDK too.

What this suggests

Given that libpalaso is the only blocker and is mid-cycle on 10.0.0-beta, the low-friction path is to
multi-target net8.0;net10.0 (and net8.0-windows;net10.0-windows) rather than replace, then
drop net8.0 in a later major once libpalaso has moved. That keeps the change +semver:minor,
unblocks .NET 10 consumers immediately, and gives libpalaso a window to bump its own matrix. If we do
want to replace outright, it should land alongside a libpalaso PR, not before one.

---

Survey and analysis by Claude Opus 5 (1M context) (claude-opus-5[1m]) via Claude Code.

[imnasnainaec]

Impact on Bloom

Following up on the sillsdev survey above, since BloomDesktop is the largest consumer outside the
org. It turns out to be the strongest argument against replacing net8.0 outright: Bloom is
simultaneously the most up-to-date consumer of L10NSharp anywhere and the one most exposed to this
change.

Bloom is exactly the configuration we'd be dropping

All three projects in Bloom.sln single-target net8.0-windows:

Project	TFM	L10NSharp
src/BloomExe/BloomExe.csproj	net8.0-windows (LangVersion 11.0, RuntimeIdentifiers win-x64;win-arm64)	L10NSharp 10.0.0-beta0005
src/BloomTests/BloomTests.csproj	net8.0-windows	L10NSharp 10.0.0-beta0005
src/WebView2PdfMaker/WebView2PdfMaker.csproj	net8.0-windows	(via SIL.Core)

Note the version: 10.0.0-beta0005, which is ahead of libpalaso's 10.0.0-beta0004. Bloom tracks us
closely, so "they're far behind anyway" isn't an available excuse here.

The exposure is through a transitive reference

BloomExe.csproj directly references only the core L10NSharp package — which is netstandard2.0
and therefore not affected by this issue. But Bloom has using L10NSharp.Windows.Forms; in 17
source files, including Program.cs, Workspace/WorkspaceView.cs and roughly a dozen .Designer.cs
files wiring up L10NExtender. That package arrives transitively via
SIL.Windows.Forms 18.0.0-beta0028.

So the failure chain is:

1. L10NSharp.Windows.Forms drops net8.0-windows
2. libpalaso must move SIL.Windows.Forms / SIL.Windows.Forms.Keyboarding to net10.0-windows
3. Bloom's net8.0-windows build loses the assets for a package it compiles against but never
   declares — and being single-target, it cannot straddle both while it migrates

Worth noting independently of this issue: compiling against a transitive package reference is fragile
regardless of TFMs, and Bloom would be better off declaring L10NSharp.Windows.Forms explicitly. Not
our call, but it's the kind of thing that turns a version bump into a confusing restore error.

Bloom's migration is not a one-line TFM bump

Things in the way on their side, which is why we shouldn't assume they can move on our schedule:

• RuntimeIdentifiers win-x64;win-arm64, with per-RID native DLL copying for SIL.Media and SQLite
• Velopack installer pinned to a custom build (VelopackVersion 0.0.1350-l10n-0020 in
  Directory.Build.props) plus the Squirrel upgrade path
• WebView2, and a separate WebView2PdfMaker executable that Bloom shells out to by filename
• CI: both nightly.yml and harvester-artifacts.yml install dotnet-version: 8.0.x

One thing that is not a problem: Bloom doesn't use ExtractXliff at all (zero hits in the repo) —
it localizes through Crowdin and SIL.libpalaso.l10ns. So the tool packages' TFM is irrelevant to
them.

Conclusion

This strengthens the recommendation from the previous comment. Multi-targeting
net8.0-windows;net10.0-windows lets libpalaso and Bloom adopt .NET 10 when their own installer,
native-dependency and CI work is ready, instead of us forcing a flag-day migration through two repos
we don't control. .NET 8 goes out of support 2026-11-10, so Bloom has to move regardless — but that
should be their deadline to plan against, not one we manufacture.

(Surveyed BloomBooks/BloomDesktop master only; other branches and any private Bloom repos aren't
covered.)

---

Survey and analysis by Claude Opus 5 (1M context) (claude-opus-5[1m]) via Claude Code.

[tombogle]

I think with some of the other things pending in L10nSharp, we'd be better off releasing a version with both and maintaining .Net 8 until it is no longer supported.