Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot run global tool after installing it, must open new command prompt #8368

Closed
danroth27 opened this issue Jan 11, 2018 · 32 comments

Comments

Projects
None yet
@danroth27
Copy link
Member

commented Jan 11, 2018

After I have successfully installed a global tool I am not able to run it without opening a new command prompt:

C:\Users\daroth\Desktop\test>dotnet install tool dotnet-dev-certs --version 2.1.0-preview1-28051

The installation succeeded. If there is no other instruction. You can type the following command in shell directly to invoke: dotnet-dev-certs

C:\Users\daroth\Desktop\test>dotnet dev-certs -h
No executable found matching command "dotnet-dev-certs"

C:\Users\daroth\Desktop\test>dotnet-dev-certs -h
'dotnet-dev-certs' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\daroth\Desktop\test>dotnet dev-certs
No executable found matching command "dotnet-dev-certs"

@wli3 wli3 self-assigned this Jan 11, 2018

@wli3

This comment has been minimized.

Copy link
Collaborator

commented Jan 11, 2018

Did you just installed SDK? It requires a restart of command prompt in order for PATH in registry to work. However there should be an error message to tell the user to restart.

@livarcocc livarcocc added this to the 2.2.0 milestone Jan 11, 2018

@livarcocc

This comment has been minimized.

Copy link
Member

commented Jan 18, 2018

@danroth27 can you give us the info @wli3 is asking for above?

@wli3

This comment has been minimized.

Copy link
Collaborator

commented Feb 9, 2018

We could either add these windows specific code

or add instruction to reopen cmd

@danroth27

This comment has been minimized.

Copy link
Member Author

commented Feb 9, 2018

Yes, opening a new command prompt works, but I don't think that's the user experience we want. You should be able to install a global tool and use it immediately. That's how npm global tools work, right?

/cc @KathleenDollard

@livarcocc

This comment has been minimized.

Copy link
Member

commented Feb 9, 2018

This is only a problem for when dotnet is first installed and I believe is a similar behavior as npm actually. It is not a matter of I ran install or not. It is a matter of I just got this CLI.

@danroth27

This comment has been minimized.

Copy link
Member Author

commented Feb 9, 2018

Oh, so this is a one time thing?

@wli3

This comment has been minimized.

Copy link
Collaborator

commented Feb 9, 2018

one time per user

@danroth27

This comment has been minimized.

Copy link
Member Author

commented Feb 9, 2018

Ah, ok. I think that's fine then.

@KathleenDollard

This comment has been minimized.

Copy link

commented Feb 11, 2018

Will can you put the new text in this issue? I think it would tidy up this issue prior to closing it.

We updated that "If there are no further instructions" and I thought it was a but more clear in the install that the restart was needed.

@wli3

This comment has been minimized.

Copy link
Collaborator

commented Feb 12, 2018

I haven't put the change in yet. According to #8369

We want to use the following

The installation succeeded and you can run the tool by typing: dotnet-dev-certs
(If you the tool is not found, try restarting your shell)
@KathleenDollard

This comment has been minimized.

Copy link

commented Feb 13, 2018

Cool, that will the new text be in Preview 1?

@wli3

This comment has been minimized.

Copy link
Collaborator

commented Feb 13, 2018

No, it won't be in preview 1. But that's what we decided so far. Do we want to add more to it according to this thread?

@wli3

This comment has been minimized.

Copy link
Collaborator

commented Feb 13, 2018

@KathleenDollard Above is not in preview 1. What in preview 1 is issue description's version.

@dasMulli

This comment has been minimized.

Copy link
Contributor

commented Feb 13, 2018

could something be done to test if the directory that the shim was written to is not yet on the current PATH?

@wli3

This comment has been minimized.

Copy link
Collaborator

commented Feb 13, 2018

@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

@peterblazejewicz

This comment has been minimized.

Copy link

commented Mar 1, 2018

With official preview release (macOS):

dotnet install tool dotnet-dev-certs -g --version 2.1.0-preview1-final
Since you just installed the .NET Core SDK, you will need to reopen terminal before running the tool you installed.
The installation succeeded. If there are no further instructions, you can type the following command in shell directly to invoke: dotnet-dev-certs

and:

dotnet-dev-certs
command not found: dotnet-dev-certs

I'd suggest to rephrase it to dotnet dev-certs - is this works
thanks!

@StefH

This comment has been minimized.

Copy link

commented Sep 12, 2018

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"
@KathleenDollard

This comment has been minimized.

Copy link

commented Sep 12, 2018

@StefH

If you just installed the SDK, the path to your global tools you need to restart the shell for the path to global tools to be recognized.

Are you installing and running via a script? (where this would be quite problematic)

If so @wli3 can he set the path explicitly in the script to avoid the problem?

@wli3

This comment has been minimized.

Copy link
Collaborator

commented Sep 13, 2018

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.

@dasMulli

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2018

+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

@StefH

This comment has been minimized.

Copy link

commented Sep 13, 2018

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 microsoft/azure-pipelines-tasks#8291

@ignatandrei

This comment has been minimized.

Copy link

commented Sep 20, 2018

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

@cosmoKenney

This comment has been minimized.

Copy link

commented Sep 26, 2018

@ignatandrei Same here. VSTS Pipeline stopped working -- unable to find the tool installed in a previous step.

@ignatandrei

This comment has been minimized.

Copy link

commented Sep 26, 2018

@cosmoKenney : After reporting as a bug (https://developercommunity.visualstudio.com/content/problem/340067/install-global-tool.html?childToView=343864#comment-343864 ) , found an workaround until the bug is solved:

See the https://github.com/ignatandrei/stankins/blob/master/azure-pipelines.yml

steps:

  • task: DotNetCoreInstaller@0
    displayName: 'Use .NET Core sdk 2.1.300'
    inputs:
    version: 2.1.300

  • script: |
    dotnet tool install --tool-path . dotnetsay
    .\dotnetsay
    displayName: 'Command Line Script'

( I do prefer putting on current dir rather to be based on %USERPROFILE%.dotnet\tools\ folder that can change at a future release . It is still a workaround)

@cosmoKenney

This comment has been minimized.

Copy link

commented Sep 26, 2018

@ignatandrei I really don't understand the yaml. Did you switch to a CMD task?

@ignatandrei

This comment has been minimized.

Copy link

commented Sep 26, 2018

Yes.

@bishal-pdMSFT

This comment has been minimized.

Copy link

commented Sep 27, 2018

@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?

@cosmoKenney

This comment has been minimized.

Copy link

commented Sep 27, 2018

+1 on reopening this issue. Using the CMD step [workaround] to install the tool using --tool-path doesn't work if you install a tool to some arbitrary folder. Then if you use the tool in a following step in the pipeline, you still don't have access to the tool. If there were a variable you could use with a path in both steps that would help mitigate the issue.

@wli3

This comment has been minimized.

Copy link
Collaborator

commented Sep 27, 2018

I created a new thread for Azure DevOps CI issue #10059

@stamminator

This comment has been minimized.

Copy link

commented Nov 16, 2018

Does this limitation apply in Linux as well, or are the environment variables available as soon as the tool is installed without having to restart the shell?

@KathleenDollard

This comment has been minimized.

Copy link

commented Nov 19, 2018

@wli3

This comment has been minimized.

Copy link
Collaborator

commented Nov 19, 2018

Hi @stamminator

Does this limitation apply in Linux as well, or are the environment variables available as soon as the tool is installed without having to restart the shell?

This applies to Linux if you install it via package manager like apt-get. You need to re log in your shell in order to source the script we put in /etc/profile.d which will append to $PATH.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.