Current directory in `dotnet run` and VS F5 is different
See original GitHub issueThis 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.
Issue Analytics
- State:
- Created 5 years ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
breaking changes in current directory
Run this project from: dotnet build & dotnet run - There will be the directory where Program.cs is located in the output; VS...
Read more >What is different between visual studio F5, ctrl+F5, or ...
I have written a program in vc++ that has different behavior in various case as below. When I run it by F5 it...
Read more >Debug a .NET console application using Visual Studio Code
Another way to continue is by pressing F5 . Continue debugging. Select the Terminal tab again. The values displayed in the console window ......
Read more >K81271448: Merging BIG-IP configuration objects into the ...
You want to create or modify BIG-IP configuration objects by merging the configuration changes into the existing running configuration from ...
Read more >Run and debug .NET executables without source code
Once the configuration is created, you can launch it with the debugger attached Alt F5 or without debugging Ctrl F5 . In case...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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 isdotnet run
when aRunWorkingDirectory
property is set in the project file. However, I haven’t spent the time to track down the discrepancy yet fordotnet 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.Based on dotnet/sdk#7011, it seems this is a VS issue.
Does this affect binding? It seems it shouldn’t.