Dotnet is not found under default PATH

[NinoFloris]

Environment data

dotnet --info output:
.NET Command Line Tools (1.0.0-rc4-004849)

Product Information:
Version: 1.0.0-rc4-004849
Commit SHA-1 hash: 7dcefb5076

Runtime Environment:
OS Name: Mac OS X
OS Version: 10.12
OS Platform: Darwin
RID: osx.10.12-x64
Base Path: /usr/local/share/dotnet/sdk/1.0.0-rc4-004849
VS Code version: 1.10.0-insider
C# Extension version: 1.7.0

Steps to reproduce

Dotnet is not found under default path folders.

This results in .net cli errors from the c# extension and a failure to debug/restore and build, omnisharp works fine though.

Tested with cli from dot.net, rc3 and latest bits on a clean Sierra installation.

Installer correctly installs path into /etc/paths.d but this is not picked up by the extension (failed to run path_helper?).

The PATH in the integrated terminal is completely fine but looking at dev tools in vscode and running process.env gives the default PATH of: PATH: "/usr/bin:/bin:/usr/sbin:/sbin" where dotnet of course cannot be found.

Running code from the terminal where it gets populated with a bigger path does have the desired effect but is cumbersome and a roundabout way to solving this.

[gregg-miskelly]

@NinoFloris this isn't really an issue with the extension -- for things to work somehow dotnet needs to be on the PATH that the extension runs under. We have had a few folks report similar problems before. Look at #555 (skip the first few entries as that was back when we tried to interpret the PATH ourselves) for some of the things that have worked for others.

[NinoFloris]

Yep I've seen this issue and specifically added the question about whether or not vscode/this ext correctly uses path_helper to get a well defined PATH from the os. As yes my dotnet is on PATH but the difference with windows is that your app launcher PATH is not equal to your terminal path. launchd by design will not auto load something like path_helper output into it's own PATH. However you cannot tell me that the OOBE on osx should just be broken. So say I'm a new dev wanting to try vscode with dotnet core. I run the official CLI installer and i install the official c# extension in my official vscode on osx. "Cannot find dotnet binary". I'd quit and go do node or something. Default state == broken and that is just fine?

…

On Wed, Feb 22, 2017, 17:57 Gregg Miskelly ***@***.***> wrote: @NinoFloris <https://github.com/NinoFloris> this isn't really an issue with the extension -- for things to work somehow dotnet needs to be on the PATH that the extension runs under. We have had a few folks report similar problems before. Look at #555 <#555> (skip the first few entries as that was back when we tried to interpret the PATH ourselves) for some of the things that have worked for others. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1259 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEBfuXeW6IhqzCZZhJK3ttSWprlB0CxQks5rfGjmgaJpZM4MItm5> .

[gregg-miskelly]

@NinoFloris for all the clean install MacOS boxes we have, whatever the .NET CLI is doing to add itself to PATH, it shows up in the PATH for VS Code. So I think you must have some sort of configuration nob set that causes this. Though what that is I have no idea.

If you have a tasks.json entry that spawns dotnet to build. Do you run into the same problem?

If VS Code is already somehow using path_helper but it isn't getting used by the extension, then we can certainly fix it. But otherwise we will at least need a VS Code side fix. I am afraid I don't know all that much about this area.

[NinoFloris]

Sadly the same is true for tasks yes. I have no clue why vscode only has the default path entries loaded and the terminal has all of the PATHS (which I know requires some gymnastics for vscode to populate with a full PATH, as I had an older issue for an issue about that)

[gregg-miskelly]

@dbaeumer @chrisdias @blackdwarf do any of you know enough about PATH handling on MacOS to comment on if VS Code should somehow be using path_helper to ensure that paths added in /etc/paths.d (I am assuming this is where the .NET CLI adds itself at least) are in the PATH environment variable for tasks.json tasks?

If this isn't a bug, any guess as to why this isn't happening for @NinoFloris automatically?

[blackdwarf]

@gregg-miskelly the path_helper gets called for new login shells, I believe, by default. In general, the path_helper is not supposed to be run by GUI apps. This is guidance, I don't know if anything untoward would happen if you do since it reads the etc/paths.d/ entries and constructs the default $PATH and $MANPATH from it.

[NinoFloris]

How do you discover dotnet then?
Let me rephrase, what techniques are currently used by this extension's dotnet restore command to find the dotnet binary?

If it's just start a vscode child process dotnet args: restore then it's obvious that it can't work with the default PATH that osx gives to apps launched through launchd. (as that's just PATH: "/usr/bin:/bin:/usr/sbin:/sbin")

EDIT:
Yes path_helper is really not much more than something that reads etc/paths.d/* and etc/path so you can source its output.

And yes as seen in commands.ts there is just a spawn with env: process.env which cannot work if the vscode PATH is the default launchd PATH, dotnet is only found under /usr/local/share which is not a default PATH entry

[NinoFloris]

But it starts to look like this is a vscode wide issue as tasks for instance exhibit the same problems.
Something must have changed related to PATH handling on OSX in recent releases.

[blackdwarf]

@NinoFloris are you using Sierra?

I don't understand the question about restore, though. Do you mean to say that VS Code can run dotnet restore and that is the only command that works?

[NinoFloris]

Yes

About dotnet restore, you are relying on the shell to expand this dotnet command via env (PATH) to an existing path right? Well if you take the vscode process env which is set to launchd defaults, as launchd spawned it you will never be able to execute dotnet as it is not found in those paths

[NinoFloris]

which is what I get on all commands involving dotnet

install

Finished
Failed to spawn 'dotnet --info'

restore

ERROR: Error: spawn dotnet ENOENT
Done: -2.

[gregg-miskelly]

RE: How do you discover dotnet then?
As I said, for most folks, PATH automatically gets passed so this 'just works'.

[NinoFloris]

Okay found it, it was again exactly the same problem

microsoft/vscode#8434

Seems like something broke the fix as fish with powerline breaks the hacky PATH importer again

[gregg-miskelly]

Closing this issue since the root problem is a VS Code issue.