sdk: Cannot run global tool after installing it, must open new command prompt

I’ve the same error when using dotnet tool install --global *** in the new Azure Pipelines flow.

My command is like:

dotnet tool install --global dotnet-sonarscanner

This command outputs this:

Since you just installed the .NET Core SDK, you will need to reopen the Command Prompt window before running the tool you installed.
You can invoke the tool using the following command: dotnet-sonarscanner
Tool 'dotnet-sonarscanner' (version '4.3.1') was successfully installed.

And the next step will fail (running the above command in the same step or a different script step make no difference)

No executable found matching command "dotnet-sonarscanner"

@wli3 in an automated scenario like Azure pipelines(previously VSTS) this is a big problem. There is no way to open a new shell to mitigate this. Also, just adding a better message does not solve this problem. Why does dotnet tool require this extra manual step? Npm works just fine. At the minimum, dotnet tool install -g should be adding the location to PATH. Can we re-activate this issue?

Hi @dasMulli ; keep seeing you everywhere… Hi @wli3 : thanks for your solution.

For now I just solved it by providing the full path to the executable, so:

%USERPROFILE%\.dotnet\tools\dotnet-sonarscanner

See also linked issue https://github.com/Microsoft/vsts-tasks/issues/8291

IDK why this issued has been closed. It still doesn’t work in an Azure pipeline, e.g. I can’t run AzureSignTool:

Starting: Where Is AzureSignTool?
========================== Starting Command Output ===========================
"C:\Windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "C:\a\_temp\13166de5-f63c-4bef-b378-4cf65dc24225.cmd""

C:\a\1\s>dotnet tool update --global AzureSignTool --version 3.0.0 
Tool 'azuresigntool' was reinstalled with the latest stable version (version '3.0.0').

C:\a\1\s>dotnet tool list --global 
Package Id         Version      Commands     
---------------------------------------------
azuresigntool      3.0.0        azuresigntool

C:\a\1\s>where dotnet 
C:\Program Files\dotnet\dotnet.exe

C:\a\1\s>where azuresigntool 
INFO: Could not find files for the given pattern(s).

C:\a\1\s>azuresigntool
'azuresigntool' is not recognized as an internal or external command,
operable program or batch file.

C:\a\1\s>dir /b C:\Users\AzDevOps\.dotnet\tools\azuresigntool.* 
azuresigntool.exe

C:\a\1\s>exit /b 1 

For now, using dotnet tool install --tool-path to install it locally as a workaround:

dotnet tool update --tool-path dist AzureSignTool --version 3.0.0

---

Updated for those who may end up here, like me again in 2023.

Eventually, instead of dotnet tool update --tool-path <local-path> I settled on using dotnet tool install --local.

For example:

1. Run this once manually for every dotnet tool you install, e.g.:

dotnet tool install --local AzureSignTool --version 4.0.1

This creates/updates the local file ./.config/dotnet-tools.json:

{
  "version": 1,
  "isRoot": true,
  "tools": {
    "azuresigntool": {
      "version": "4.0.1",
      "commands": [
        "azuresigntool"
      ]
    }
  }
}

1. Make sure ./.config/dotnet-tools.json is tracked in your project’s repo.

2. At any time you can restore your local dotnet tools with:

dotnet tool restore --tool-manifest ./.config/dotnet-tools.json'

I’m using this approach in my project’s CI/CD pipleline and it gives me reliable & reproducible builds.

I am facing the same issue: I’m in a Docker container, at build time on our build server.

@KathleenDollard It should be trivial to update the PATH of the current shell session in addition to the system one.

Some problem here . However, in old VSTS pipelines it works. It Azure DevOps it does not.

You could add %UserProfile%/.dotnet/tools/ to your path before running the command. Although, in script, we recommend using --too-path with explicit location instead of install it globally. And call the tool with full path.

+1 for the tool path. an example vsts / azure pipelines config usage can bee seen in msbuild: https://github.com/Microsoft/msbuild/blob/542125d86fca51bbfce5cebd6f3efd3bb36549b0/.vsts-dotnet.yml#L28-L39

@dasMulli Something similar is added. However, I think it is not working properly due to, in Windows it cannot distinguish between what will be available(in registry) and what is available in the session

@satrapu Thanks for that. Having another way is good to know. There’s a catch in what you wrote above, it is working as a byproduct of the .NET Core install by updating PATH. It just so happens you are doing a specific version install to make that happen rather than exporting the tools folder to the path. One thing to consider - outside of that workaround a local tools folder may be faster and easier than managing/updating version information and an additional SDK install task. I can simplify by using a local tool, your scenario may not allow that though.

  # Install specific .NET Core SDK version used for building the application.
  # See more here: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/tool/dotnet-core-tool-installer?view=azure-devops.
  # Installing a specific .NET Core SDK version is needed to avoid installing a .NET Core global tool in a following task and 
  # then have Azure DevOps complain that it cannot find it.
  # This issue is documented here: https://github.com/Microsoft/azure-pipelines-tasks/issues/8291.
  - task: UseDotNet@2
    name: 'install_dotnetcore_sdk_required_by_application'
    displayName: 'Install .NET Core SDK required by application'
    inputs:
      packageType: 'sdk'
      version: $(DotNetCore_SDK_Version)

vs

    - script: |
        dotnet tool install --tool-path tools dotnet-reportgenerator-globaltool
        ./tools/reportgenerator -reports:$(Agent.TempDirectory)/**/coverage.cobertura.xml -targetdir:$(Build.SourcesDirectory)/coverlet/reports -reporttypes:"Cobertura"
      displayName: Create Code coverage report

Yes.