Repository navigation
CI pipelines should use repo build scripts instead of UseDotNet@2 #706
Description
Activity
- added a commit that references this issue
on Apr 29, 2026 Why didn't the UseDotNet@2 task use the useGlobalJson parameter set to true? (There's been some updates to the task recently so it should work better)
But it makes sense you would dog food your own script directly without a wrapper.
Reacted by Michael SimonsWhy didn't the UseDotNet@2 task use the useGlobalJson parameter set to true? (There's been some updates to the task recently so it should work better)
That's a fair option. I prefer using the arcade build scripts that are standard across the dotnet repos. Currently they are checked in but don't work which leads to a frustrating dev UX for those who are accustom to using them.
Reacted by Ella Hathaway and Frulfump
Metadata
Metadata
Assignees
Type
Projects
- Status
Problem
Both the PR and official CI pipelines use the
UseDotNet@2Azure DevOps task withversion: 8.xto install the .NET SDK, bypassing the repo's own build infrastructure (eng/common/build.sh,eng/common/CIBuild.cmd).This causes several issues:
SDK version drift — The pipelines install whatever the latest 8.0.x SDK is (currently 8.0.420), which may differ from the version specified in
global.json(8.0.126). When upgrading the SDK, you have to update bothglobal.jsonand the pipeline YAML, rather than just one place.Inconsistency with local development — Developers building locally use the build scripts which honor
global.json, while CI uses a potentially different SDK version. This can mask or introduce issues that don't reproduce in the other environment.Maintenance burden — The
UseDotNet@2version must be manually kept in sync across 6 pipeline locations (3 jobs × 2 pipeline files). The build scripts already handle SDK acquisition correctly from a single source of truth.Suggestion
Replace the
UseDotNet@2task and separateDotNetCoreCLI@2test task with a single call to the repo's build scripts (eng/common/build.sh/eng/common/CIBuild.cmd). The build scripts handle SDK installation automatically (honoringglobal.json) and then build/test — consolidating two pipeline steps into one and eliminating the version drift problem.