Inconsistent WorkingDirectory behavior between Windows and Linux for File-based apps

[nicro950]

Describe the bug

On two separate Linux instances (Linux Mint (22.2) on bare metal and Ubuntu (24.04.3) in WSL), I get an unexpected path out of Environment.CurrentDirectory, Directory.GetCurrentDirectory() and new DirectoryInfo(".").FullName. All of them on linux always returns the folder of the script no matter what directory I run the dotnet command from. On windows on the other hand then this looks like it works as i expected, with all the different current directory functions returning the directory of where the terminal is, and not where the file is located.

To Reproduce

On a Linux machine or in WSL, all the following lines always return the same value, which is the script file folder. On windows, the 3 first returns the terminal working directory, while the last returns the script file folder.

I have only tested this on Linux Mint, and Ubuntu WSL.

Console.WriteLine(Environment.CurrentDirectory);
Console.WriteLine(Directory.GetCurrentDirectory());
Console.WriteLine(new DirectoryInfo(".").FullName);
Console.WriteLine(AppContext.GetData("EntryPointFileDirectoryPath"));

Navigate to a different directory then the file-based app, and run dotnet run {PathToFile}/file.cs

Exceptions (if any)

Further technical details

details of dotnet --info (Linux)

.NET SDK: Version: 10.0.100 Commit: b0f34d51fc Workload version: 10.0.100-manifests.4c0ca8ba MSBuild version: 18.0.2+b0f34d51f

Runtime Environment:
OS Name: ubuntu
OS Version: 24.04
OS Platform: Linux
RID: linux-x64
Base Path: /home/ni.../.dotnet/sdk/10.0.100/

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
Version: 10.0.0
Architecture: x64
Commit: b0f34d51fc

.NET SDKs installed:
8.0.407 [/home/ni.../.dotnet/sdk]
9.0.202 [/home/ni.../.dotnet/sdk]
10.0.100 [/home/ni.../.dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.14 [/home/ni.../.dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.3 [/home/ni.../.dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.0 [/home/ni.../.dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.14 [/home/ni.../.dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.3 [/home/ni.../.dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.0 [/home/ni.../.dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
None

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

details of dotnet --info (Windows)

.NET SDK: Version: 10.0.100 Commit: b0f34d51fc Workload version: 10.0.100-manifests.355811b7 MSBuild version: 18.0.2+b0f34d51f

Runtime Environment:
OS Name: Windows
OS Version: 10.0.22631
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\10.0.100\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
Version: 10.0.0
Architecture: x64
Commit: b0f34d51fc

.NET SDKs installed:
9.0.100-rc.2.24474.11 [C:\Program Files\dotnet\sdk]
9.0.307 [C:\Program Files\dotnet\sdk]
10.0.100-rc.2.25502.107 [C:\Program Files\dotnet\sdk]
10.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.0-rc.2.24474.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0-rc.2.24473.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.0-rc.2.24474.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

- running from command line

[jjonescz]

Thanks for reporting this issue.

On a Linux machine or in WSL, all the following lines always return the same value, which is the script file folder. On windows, the 3 first returns the terminal working directory, while the last returns the script file folder.

Weird. I'm getting the exact opposite - on Windows, all return the script folder (that's a bug); on Linux, the first three return current working directory, and the last one returns the script folder (that's the expected behavior).

[jjonescz]

Looks like this is due to an optimized build path for simple file-based apps. If you add some #: directive (or run it with --no-cache), that path won't be hit and this bug wouldn't manifest (so that's a workaround until this is fixed).