[BUG]: DotNetCoreCLI@2 global.json lookup is hardcoded to repository root

[gitmln]

New issue checklist

• I searched for existing GitHub issues
• I read pipeline troubleshooting guide
• I checked how to collect logs

Task name

DotNetCoreCLI@2

Task version

v264

Issue Description

Repository / File / Line

microsoft/azure-pipelines-tasks
Tasks/DotNetCoreCLIV2/dotnetcore.ts — around line 150
Reference: https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/DotNetCoreCLIV2/dotnetcore.ts#L150

Description

The task checks for and reads "global.json" using a hardcoded filename (e.g. if (!tl.exist("global.json")) { ... }) which assumes the file is located in the repository root (Build.SourcesDirectory) or current process cwd. This logic does not respect the task's workingDirectory parameter (or any working-directory input). It also doesn't respect dotnet sdk behavior https://learn.microsoft.com/en-us/dotnet/core/tools/global-json (The .NET SDK looks for a global.json file in the current working directory (which isn't necessarily the same as the project directory) or one of its ancestor directories.). The task fails to detect or open the correct global.json.
This is especially crucial when dealing with monorepos where many different dotnet projects coexist in the same repo. It can't be assumes that all of them need global.json file placed in the root folder.

Steps to reproduce

Configure the DotNetCoreCLIV2 task with workingDirectory set to a subfolder (e.g. src/MyProject).
Place a valid global.json in that subfolder (src/MyProject/global.json) that sets the test runner to Microsoft.Testing.Platform.
Run the pipeline. The task will behave as if global.json is missing.

Actual behavior

The task logs that global.json was not found and falls back to the default VSTest logic, ignoring the intended configuration.

Expected behavior

The task should resolve and check for global.json relative to the configured workingDirectory (if provided). The more advanced solution would be to add another parameter (rootDirectory) to set where to start searching for global.json (then checking also its ancestors).

Environment type (Please select at least one enviroment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Operation system

Ubuntu 24.04

Relevant log output

##[debug]check path : /agent/_work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.264.1/node_modules/azure-pipelines-tasks-packaging-common/module.json
##[debug]adding resource file: /agent/_work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.264.1/node_modules/azure-pipelines-tasks-packaging-common/module.json
##[debug]system.culture=en-US
##[debug]command=test
##[debug]projects=|REDACTED|
##[debug]arguments=--coverage --coverage-output-format cobertura --configuration Release
##[debug]publishWebProjects=true
##[debug]zipAfterPublish=true
##[debug]workingDirectory=/agent/_work/45/s/|REDACTED|
##[debug]check path : /agent/_work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.264.1/task.json
##[debug]adding resource file: /agent/_work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.264.1/task.json
##[debug]system.culture=en-US
##[debug]ConnectedServiceName=undefined
##[debug]No connected service set
##[debug]which 'dotnet'
##[debug]found: '/agent/_work/45/dotnet/dotnet'
Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.
##[debug]publishTestResults=true
##[debug]Agent.TempDirectory=/agent/_work/_temp
##[debug]Feature 'DisableDotnetConfigDetection' not found. Returning false as default.
##[debug]global.json not found. Test run is VSTest
##[debug]defaultRoot: '/agent/_work/_temp'
##[debug]findOptions.allowBrokenSymbolicLinks: 'false'
##[debug]findOptions.followSpecifiedSymbolicLink: 'true'
##[debug]findOptions.followSymbolicLinks: 'true'
##[debug]findOptions.skipMissingFiles: 'false'
##[debug]matchOptions.debug: 'false'
##[debug]matchOptions.nobrace: 'true'
##[debug]matchOptions.noglobstar: 'false'
##[debug]matchOptions.dot: 'true'
##[debug]matchOptions.noext: 'false'
##[debug]matchOptions.nocase: 'false'
##[debug]matchOptions.nonull: 'false'
##[debug]matchOptions.matchBase: 'false'
##[debug]matchOptions.nocomment: 'false'
##[debug]matchOptions.nonegate: 'false'
##[debug]matchOptions.flipNegate: 'false'
##[debug]pattern: '**/*.trx'
##[debug]findPath: '/agent/_work/_temp'
##[debug]statOnly: 'false'
##[debug]findPath: '/agent/_work/_temp'
##[debug]findOptions.allowBrokenSymbolicLinks: 'false'
##[debug]findOptions.followSpecifiedSymbolicLink: 'true'
##[debug]findOptions.followSymbolicLinks: 'true'
##[debug]findOptions.skipMissingFiles: 'false'

Full task logs with system.debug enabled

No response

Repro steps

[avivanoff]

I was about to file the same bug on https://developercommunity.visualstudio.com/.

[orbitalbits]

We were about to report this same bug, too. Looking at the current sources for DotNetCoreCLIV2, the executeTestCommand() function is reading the global.json file before it changes the current working directory to the value set by the workingDirectory option. If the global.json file is read after the working directory is changed to the configured path, users could configure the path correctly.

azure-pipelines-tasks/Tasks/DotNetCoreCLIV2/dotnetcore.ts

Line 175 in 4dca6cb

const isMTP: boolean = !tl.getPipelineFeature('DisableDotnetConfigDetection') && this.getIsMicrosoftTestingPlatform();