There are 3 different ways to run the script on Windows:

1. dotnet script myscript.csx
2. (after dotnet script register) just run myscript.csx
3. compile using dotnet script publish myscript.csx and then run myscript.exe

In each of these 3 cases, the Environment.GetCommandLineArgs() contains very different data.

If called using dotnet script then the fully resolved path of the DLL is the first argument, the scriptname is the second.

C:\Users\<username>\.dotnet\tools\.store\dotnet-script\1.5.0\dotnet-script\1.5.0\tools\net8.0\any\dotnet-script.dll;myapp.csx;<user-provided-arguments-start-here>

If called using the registered version, the extra separator argument "--" is added.

C:\Users\<username>\.dotnet\tools\.store\dotnet-script\1.5.0\dotnet-script\1.5.0\tools\net8.0\any\dotnet-script.dll;myapp.csx;--;<user-provided-arguments-start-here>

Finally, if compiled to .exe it behaves a conventional way - first argument is the fully-resolved path to the .exe, all following arguments are the user-provided arguments.

I have not attempted the 4th way (executing a published DLL).

Also, the Args collection is not a good substitute, since that hides all the parameters that are intercepted by dotnet-script whereas they're available in full in Environment.GetCommandLineArgs()

It is very difficult to get a clean collection of arguments to pass onto System.Commandline