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: previewThe 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: previewPossible resolutions
- Allow quality to be attached per version, for example
11.0.x:preview alongside a plain 10.0.x.
- Accept a matching list for
dotnet-quality, aligned by position with dotnet-version.
- 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.
Description
dotnet-qualityis a single input for the whole step, and it applies to every version listed indotnet-version. That makes a very common combination impossible to express: the current released SDK, plus a preview of the upcoming one.The intent here is "released 10.0, preview 11.0". What actually happens is that both are resolved at preview quality:
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.Appruntimes present are the prerelease ones bundled with the RC and the next preview:A WPF test host targeting
net10.0-windowsasks for GA10.0.0and 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:
Possible resolutions
11.0.x:previewalongside a plain10.0.x.dotnet-quality, aligned by position withdotnet-version.dotnet-qualityis 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.