.Net CLI tools not being located

[kieferrm]

Moved from https://github.com/Microsoft/vscode/issues/9810:

• VSCode Version: 1.3.1
• OS Version: windows 10 1511

Steps to Reproduce:

1. install visual studio 2015 enterprise with updates include all common tools
2. install visual studio code
3. open visual studio code
4. create file with CS extentions
5. error message appears error The .Net CLI tools cannot be located. .Net Core debugging will not be enabled. Make sure .NET CLI tools are installed and are on the path.

[gregg-miskelly]

@RMajere is VS somehow installing the .NET CLI, but not placing it on the path? My understanding was that this is expected -- VS doesn't install the .NET Core tooling and it needs to be installed from https://www.microsoft.com/net/core#windows. @blackdwarf do I have that wrong?

[ghost]

@gregg-miskelly VS is installing update 3 along with the main installer. so if I attempt to install update 3 on its own I am informed that the update is installed, when running the .NET Core 1.0 for visual studio fails stating that update 3 is either not installed or not installed correctly. here is what is currently listed in the PATH: C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0\ C:\Program Files\Microsoft SQL Server\120\Tools\Binn\ C:\Program Files\Microsoft SQL Server\130\Tools\Binn\ C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\ C:\Program Files\Git\cmd C:\Program Files\Microsoft\Web Platform Installer\ C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\ C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\ C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\ C:\Program Files\nodejs\ C:\Users\kristopher.koford\AppData\Roaming\npm C:\Program Files (x86)\Microsoft VS Code

[gregg-miskelly]

@RMajere you are running into https://github.com/dotnet/cli/issues/3933. There is a work around and the end of that bug that should fix this for you.

[doivosev]

I have the same error. I have had it before and after update to 1.6 of VS Code. I have vs 2015 and 2013 and have installed .NET CLI tools provided in the link on the error. I have C:\Program Files\dotnet\ in the path. Do I need something else in my path for vscode to recognize?

[gregg-miskelly]

@doivosev all our extension does is exec dotnet. If you open a Windows command prompt and exec where dotnet what do you get?

The output from my machine for example:

C:\Users\greggm>where dotnet
C:\Program Files\dotnet\dotnet.exe

[RanzQ]

Having this same issue, dotnet command works in Command Prompt:

>dotnet --info
.NET Command Line Tools (1.0.0-preview2-003133)

Product Information:
 Version:            1.0.0-preview2-003133
 Commit SHA-1 hash:  74df06500c

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

>where dotnet
C:\Program Files\dotnet\dotnet.exe

[gregg-miskelly]

@RanzQ what do you get if you do:

1. Open VS Code
2. View->Integrated Terminal
3. echo %path%

[RanzQ]

I see the path as it should be, including C:\Program Files\dotnet\;.

[gregg-miskelly]

If you try launching VS Code from a command prompt with a trimmed down PATH that just has what you need, does that help by chance?

[RanzQ]

@gregg-miskelly Actually I guess the problem was just an outdated PATH in VS Code. Haven't seen the error anymore. Not sure if the problem was gone after re-launching VS Code or after rebooting my PC.

[dmumladze]

The issue is that not entire %PATH% is getting loaded into VS Code. For example, I can reproduce it on Windows OS with a %PATH% variable that is up to 2k chars long and if I add the dotnet.exe location at the end. Moving the location at the beginning of the $PATH% variable solves the issue.

[Venryx]

Had a similar problem myself: even with the CLI on the path, and after restarting VSC, it still said it couldn't find the CLI tools, and the VSC terminal failed to see it.

What fixed it for me is restarting the program which was used to launch VSC each time (Unity3D).

I forgot that the PATH of the parent process is copied to the child process when launched from an existing process, rather than a new terminal or Windows explorer or the like.

Restarting should also have fixed this, though I wanted to do so without restarting as I had/have other programs open.

[mohammad-abdulkhaliq]

@dmumladze can confirm moving the dotnet path to the beginning of the path variable worked for me. The only thing that worked actually.

Thanks a lot !.

[xanthalas]

In case it helps anyone, I came across this issue whilst setting up VSCode and dotnet on Fedora 26. When starting it using DMenu (under the i3 Window Manager) it was not finding the tools. When starting it from the terminal it worked fine. This is because I have the path to the dotnet tools added in my .zshrc and that doesn't appear to be picked up when starting from DMenu.

[CollinChaffin]

Yes this should absolutely NOT be a closed issue. The code is preventing this app from reading the entire path, which if KB patch from MS is applied, can be increased past 2048 using KB2685893 associated hotfix. So, anytime the dotnet cli SDK falls after 2047, vscode vomits which is why moving it up in the list as a hokey workaround, currently works.

[gregg-miskelly]

@CollinChaffin I am not totally clear on what you are suggesting, but if you think there is something that VS Code should be doing better, please open an issue at https://github.com/Microsoft/vscode/issues. If you think there is something that the .NET CLI should be doing, please open an issue at https://github.com/dotnet/cli/issues.

[zyzil]

This may not be the best place to post this, but I ran into this error and after a lot of effort found out that it was due to having the environment variable COREHOST_TRACE=1. I forgot to remove this previously and it was causing the dotnet --info output to exceed a limit in electron. The underlying error was "stdout maxBuffer exceeded".

[CollinChaffin]

@gregg-miskelly Greg it was self-explanatory. You can apply a hotfix (been around for ages) to almost all versions of Windows prior to 10 to increase PATH length past 2048. If you have that applied, VSCode will blow up and exhibit this bug because IT, despite also being a MS product, does not know that there is a hotfix and it is possible to have a path longer.....so it simply never tries to parse it past 2048 so what happens when all of our up-to-date patched OS' place cli at the end of path at install?

I did report this as I'm certain did others. I was merely stating here that this is occurring to save others a ton of time who forgot they applied that fix years ago seeing cli in their path, and wondering why VScode simply refuses to see it and why on earth moving it up on the list matters when it should not - THIS IS WHY.

[gregg-miskelly]

@CollinChaffin Thanks for the clarification. I can't find an issue about this in https://github.com/Microsoft/vscode/issues. They are more likely to consider a bug from a customer than a bug from me, so if you can't find one either and would like to see this fixed, I would encourage you to open a bug.

[aadesola]

I had a similar issue and restarting my system worked.

[ghost]

It's 2019 now and I have the exact same issue, and reboot does not work!

[rchande]

@shcheah Please file a new issue and include:

• output of dotnet --info
• Output of your "omnisharp log"

Thanks!