Add current directory to "Unable to find project root" error

[ejizba]

We had an issue in the VS Extension (https://github.com/Microsoft/vscode-azurefunctions/issues/1175) where the user kept getting this error:

> Executing task: func host start <

Unable to find project root. Expecting to find one of host.json, local.settings.json in project root. The terminal process terminated with exit code: 1

This was the root cause as described by @petmat

I'm using Powershell as the integrated terminal in Visual Studio Code. Some time ago I set the profile file to do the following things:

Set-Location C:\

I did that because the default way Powershell works is that when you start it the default folder is the profile-folder in Windows and I would prefer it to be the root of the C-drive.

However this has an unwanted side-effect of forcing the integrated terminal in Visual Studio Code to always open in the same C:\ directory.

It feels like some of the headache could've been saved if the error message had the current directory in the message. Something like this:

Unable to find project root in folder "C:\". Expecting to find one of host.json, local.settings.json in project root. The terminal process terminated with exit code: 1

[o-o00o-o]

Having the same problem when trying to debug in vscode. I had to remove the set-location in the profile called by vscode powershell profile

I can see the tasks.json has the correct cwd in but I guess that it is getting run before the profile is run - shouldn't this be applied after the $profile is executed?

Is this appropriate in here or should I raise this somewhere else?

The OP indicated that a better error message is what is needed but for me it feels like we should be able to set a different location in our powershell profile and the tool should cope with it?

[ejizba]

it feels like we should be able to set a different location in our powershell profile and the tool should cope with it?

The problem is there are many times where ignoring the PowerShell profile would be a bug. It's used for many things other than Set-Location (like setting environment variables) which people might still want to happen. That being said, I feel like this should be completely customizable. I went ahead and filed an issue on VS Code to add support for a setting like terminal.integrated.automationShell.shellArgs.windows: https://github.com/microsoft/vscode/issues/96732

If they added support for that, you could add -NoProfile to the args so that the profile is ignored for tasks/debugging

[o-o00o-o]

I'm not suggesting you should ignore the powershell profile, I agree that wouldn't be sensible. Therefore, while it might a a workaround I'm not sure adding a NoProfile (or an environment variable to detect in the profile perhaps) is a very elegant or satisfactory solution. It feels like that might just cause more problems as this isn't specific to just the Azure Functions debugger and I can imagine that other cases using the integrated shell wouldn't want/need the same behaviour.

Isn't is possible for the cwd to be set just before the debugger starts so it starts in the right place and works regardless of what is in the profile? Surely the tool should control its own environment and ensure that dependencies it needs are reliably there.

[ejizba]

It feels like that might just cause more problems as this isn't specific to just the Azure Functions debugger

To be fair though, using Set-Location in your PowerShell profile already causes more problems that are not specific to the Azure Functions debugger. I honestly don't use PowerShell that often, but perhaps there's another way to achieve your desired behavior without doing this

Isn't is possible for the cwd to be set just before the debugger starts so it starts in the right place and works regardless of what is in the profile? Surely the tool should control its own environment and ensure that dependencies it needs are reliably there.

The problem is that it's the "right place" for your situation, but not necessarily the "right place" for other people. The tool can never fully control something like this because there's too many situations with different opinions on what's right. At the moment, it opens the shell in cwd and then executes the profile. I'm sure plenty of people like that behavior. I think the best VS Code can do is provide settings to customize it. I suggested a shellArgs setting would help (obviously you can provide args other than -NoProfile), but at this point I would suggest you file an issue on VS Code if you have other ideas