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

Abierto
  • ¿Algo no está bien?
#165 5 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

  • #172 de @imnasnainaec — cerrado sin fusionar

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
csharp, github-actions
Área
build-system, ci-cd, testing

Línea de trabajo

Primero determina si se debe reemplazar net8.0 o añadir net10.0 junto a él, utilizando la encuesta a los consumidores de los comentarios. Después actualiza los archivos de proyecto indicados y .github/workflows/CI-CD.yml, e inspecciona .github/workflows/codeql.yml, GitVersion.yml y Directory.Build.props para detectar problemas de compatibilidad. Ejecuta la compilación de la solución y los comandos de prueba de Windows/Linux; después verifica SampleApp y el contenido y la versión del paquete generado.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C#
Estrellas
3
Forks
10
Merge medio
2 h
PR fusionados (30 d)
2

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sillsdev/l10nsharp

Todos los issues de sillsdev/l10nsharp

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.