search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.68k stars 1.06k forks source link

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

Open vitek-karas opened 5 years ago

vitek-karas commented 5 years ago

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.

vitek-karas commented 5 years ago

/cc @sdmaclea @jeffschwMSFT

vitek-karas commented 5 years ago

Might be related to dotnet/sdk#9695 as well.

sdmaclea commented 5 years ago

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.

vitek-karas commented 5 years ago

@sdmaclea I wanted to start the discussion in CLI, if everybody agrees it should be changed only in VS, then we can move it there.

Not the low-level binder, that should not be affected. But it does affect some higher-level functionality. For example Assembly.LoadFrom can be called with a relative path, in which case it is affected.

livarcocc commented 5 years ago

cc @peterhuene

peterhuene commented 5 years ago

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.

vitek-karas commented 5 years ago

The VS side is being discussed in dotnet/project-system#3619