Current directory in `dotnet run` and VS F5 is different

This is basically continuation of the discussion in issue dotnet/sdk#7011. Visual Studio on a new .NET Core Console app sets the current directory to the output directory (so for example /project/bin/Debug/netcoreapp2.2). dotnet run sets the current directory to the directory from which it was executed - which typically is the project directory (so in our example /project).

Per dotnet/sdk#7011 the original design was to make VS behave the same as dotnet run and per this comment at some point it actually did, but it’s not the case anymore.

This can cause issues for the app when trying to locate files.

[peterhuene]

I suspect dotnet/sdk#9695 is coming from the test tools as there are only two places where the current working directory of a child process is modified by the CLI (afaik): one is a dotnet migrate legacy code path and the other is dotnet run when a RunWorkingDirectory property is set in the project file. However, I haven’t spent the time to track down the discrepancy yet for dotnet test.

Regarding dotnet run CWD: in general, I have a strong opinion that command line tools should always respect the CWD so that arguments are always relative to where the tool was invoked. Since this is usually the project file directory, I think a sane and consistent UX would be to also have the project directory used as CWD when F5’ing in VS.

[sdmaclea]

Visual Studio on a new .NET Core Console app sets the current directory to the output directory (so for example /project/bin/Debug/netcoreapp2.2).

Based on dotnet/sdk#7011, it seems this is a VS issue.

This can cause issues for the app when trying to locate files.

Does this affect binding? It seems it shouldn’t.