`dotnet run app.cs` does not work when ran from Linux filesystem root

[lbussell]

Describe the bug

dotnet run app.cs does not work when app.cs is in the filesystem root directory.

To Reproduce

It's easiest to reproduce this in a container image.

First start a shell inside the .NET 10 RC2 SDK image with docker run -it --rm mcr.microsoft.com/dotnet/sdk:10.0@sha256:4a57c5c3fb3ac9fb86b4a00eef3dd98fd65c73848bf21c0fc620613dcef61491.

root@c80ba46f8830:/# pwd
/
root@c80ba46f8830:/# echo 'Console.WriteLine("Hello world");' > app.cs
root@c80ba46f8830:/# cat app.cs
Console.WriteLine("Hello world");
root@c80ba46f8830:/# dotnet run app.cs
CSC : error CS2007: Unrecognized option: '/app.cs'

If we try it from a directory it works:

root@c80ba46f8830:/# mkdir test && cd test && pwd
/test
root@c80ba46f8830:/test# mv /app.cs /test/app.cs
root@c80ba46f8830:/test# dotnet run app.cs
Hello world

Exceptions (if any)

CSC : error CS2007: Unrecognized option: '/app.cs'

Further technical details

dotnet --info output:

.NET SDK:
 Version:           10.0.100-rc.2.25502.107
 Commit:            89c8f6a112
 Workload version:  10.0.100-manifests.8798a653
 MSBuild version:   18.0.0-preview-25502-107+89c8f6a11

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  24.04
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/10.0.100-rc.2.25502.107/

.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-rc.2.25502.107
  Architecture: x64
  Commit:       89c8f6a112

.NET SDKs installed:
  10.0.100-rc.2.25502.107 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 10.0.0-rc.2.25502.107 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 10.0.0-rc.2.25502.107 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_GENERATE_ASPNET_CERTIFICATE       [false]
  DOTNET_NOLOGO                            [true]
  DOTNET_ROLL_FORWARD                      [Major]
  DOTNET_RUNNING_IN_CONTAINER              [true]
  DOTNET_SDK_VERSION                       [10.0.100-rc.2.25502.107]
  DOTNET_USE_POLLING_FILE_WATCHER          [true]
  DOTNET_VERSION                           [10.0.0-rc.2.25502.107]

global.json file:
  Not found

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

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

[jjonescz]

Thanks for reporting this.

Looks like a known csc limitation - /xyz is ambiguous between a compiler option and a file in the root folder on Unix. Not sure there is a tracking issue but I've found it mentioned in dotnet/roslyn#401.

So presumably, this would happen with project-based apps too, it's not limited to file-based apps.

[KalleOlaviNiemitalo]

I imagine SDK could transform the file path to /./xyz before passing it to csc.

[jjonescz]

I think the fix for this will live in Roslyn, tracking it there: dotnet/roslyn#80865