Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

dotnet-quality applies to every entry in dotnet-version, so "stable current + preview of next" is not expressible

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

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github-actions, typescript
Área
ci-cd

Línea de trabajo

Comienza con la documentación del README sobre dotnet-version y dotnet-quality, y luego sigue cómo la action gestiona esas entradas. El objetivo se cumple cuando un paso puede solicitar released 10.0 y preview 11.0 de forma independiente, mientras el workaround existente de pasos separados y el comportamiento del runtime siguen siendo correctos.

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

Descripción

feature request
Description

dotnet-quality is a single input for the whole step, and it applies to every version listed in dotnet-version. That makes a very common combination impossible to express: the current released SDK, plus a preview of the upcoming one.

- uses: actions/setup-dotnet@v6
  with:
    dotnet-version: |
      10.0.x
      11.0.x
    dotnet-quality: preview

The intent here is "released 10.0, preview 11.0". What actually happens is that both are resolved at preview quality:

install-dotnet.ps1 -SkipNonVersionedFiles -Channel 10.0 -Quality preview
dotnet-install: .NET Core SDK with version '10.0.100-rc.2.25502.107' is already installed.

install-dotnet.ps1 -SkipNonVersionedFiles -Channel 11.0 -Quality preview
dotnet-install: .NET Core SDK with version '11.0.100-preview.7.26381.103' is already installed.

Even though 10.0 has shipped, the 10.0 request resolves to a release candidate. Combined with the "is already installed" short-circuit, a runner that once had the RC never moves to the released SDK.

Why we want both

We build against the current released SDK, and additionally install the next preview to compile a small amount of code with the upcoming C# language preview features (<LangVersion>preview</LangVersion>). That is a normal thing to want: production builds on the stable toolchain, plus early exposure to the next language version. It is not "give me previews of everything".

Impact beyond picking the wrong SDK

The knock-on effect is easy to miss. Because no released 10.0 SDK is ever installed, the only Microsoft.WindowsDesktop.App runtimes present are the prerelease ones bundled with the RC and the next preview:

Framework: 'Microsoft.WindowsDesktop.App', version '10.0.0' (x64)
The following frameworks were found:
  10.0.0-rc.2.25502.107
  11.0.0-preview.7.26381.103

A WPF test host targeting net10.0-windows asks for GA 10.0.0 and will not roll forward onto a release candidate, nor across a major version, so it fails to launch. The build still succeeds, because selecting an SDK and finding a matching runtime are different things - which makes this fail late and confusingly.

Workaround

Two steps, which works but is more verbose and easy to get wrong:

- uses: actions/setup-dotnet@v6
  with:
    dotnet-version: 10.0.x

- uses: actions/setup-dotnet@v6
  with:
    dotnet-version: 11.0.x
    dotnet-quality: preview
Possible resolutions
  1. Allow quality to be attached per version, for example 11.0.x:preview alongside a plain 10.0.x.
  2. Accept a matching list for dotnet-quality, aligned by position with dotnet-version.
  3. At minimum, document clearly that dotnet-quality is step-wide and that mixing qualities requires separate steps - the current README reads as though it qualifies each requested version.

Option 1 seems the smallest change for callers and keeps everything in one step.

Lenguaje dominante
TypeScript
Estrellas
1.2k
Forks
573
Sin PR fusionados en 30 d

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

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 actions/setup-dotnet

Todos los issues de actions/setup-dotnet

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.