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

Aperta
  • Qualcosa non va?
#165 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

  • #172 di @imnasnainaec — chiusa senza merge

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp, github-actions
Ambito
build-system, ci-cd, testing

Direzione di ricerca

Per prima cosa stabilisci se sostituire net8.0 o aggiungere net10.0 insieme a esso, utilizzando il sondaggio degli utenti nei commenti. Quindi aggiorna i file di progetto elencati e .github/workflows/CI-CD.yml, e analizza .github/workflows/codeql.yml, GitVersion.yml e Directory.Build.props per individuare problemi di compatibilità. Esegui la compilazione della soluzione e i comandi di test Windows/Linux, quindi verifica SampleApp e il contenuto e la versione del pacchetto generato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

.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 #161
    already had to adjust for API removals. (Related: #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.

Lingua principale
C#
Stelle
3
Fork
10
Merge medio
2h
PR unite (30g)
2

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sillsdev/l10nsharp

Tutte le issue di sillsdev/l10nsharp

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.