Environment.ProcessPath / Environment.GetCommandLineArgs()[0] discrepancies

[xoofx]

Hello there, ☺️

This issue is related to the following previous issues (and there are more closed):

• Environment.CommandLine for published  #11305
• How to get current process invocation name (argv[0]/$0)? (login shell on *nix) #30212

Environment.ProcessPath and Environment.GetCommandLineArgs()[0] are behaving quite differently (See the follow parts for more details):

• between them
• between platforms
• between regular dotnet built app and NativeAOT
• When we access the exe through a symbolic link

This is quite problematic when trying to build apps that expect to recover the C/C++ equivalent of argv[0] which should give exactly what was typed on the command line (e.g if it is a symbolic link, we should keep its name), and not something else.

Reproducible steps

Windows - .NET 8.0

Powershell with admin rights (for the symbolic link):

dotnet new console -n HelloWorld
cd HelloWorld
Write-Output "Console.WriteLine($""Environment.ProcessPath: {Environment.ProcessPath}"");" > Program.cs
Write-Output "Console.WriteLine($""Environment.GetCommandLineArgs()[0]: {Environment.GetCommandLineArgs()[0]}"");" >> Program.cs
dotnet build -c Release
cd .\bin\Release\net8.0

Then we create a symbolic link from special_hello.exe to HelloWorld.exe:

New-Item -ItemType SymbolicLink -Path special_hello.exe -Value HelloWorld.exe
.\special_hello.exe

Outputs:

Environment.ProcessPath: C:\code\HelloWorld\bin\Release\net8.0\special_hello.exe
Environment.GetCommandLineArgs()[0]: C:\code\HelloWorld\bin\Release\net8.0\HelloWorld.dll

Windows - NativeAOT .NET 8.0

Similar steps then before, but with dotnet publish -c Release -p:PublishAot=true

cd .\bin\Release\net8.0\win-x64\publish
New-Item -ItemType SymbolicLink -Path special_hello.exe -Value HelloWorld.exe
.\special_hello.exe

Outputs:

Environment.ProcessPath: C:\code\HelloWorld\bin\Release\net8.0\win-x64\publish\special_hello.exe
Environment.GetCommandLineArgs()[0]: C:\code\HelloWorld\bin\Release\net8.0\win-x64\publish\special_hello.exe

MacOS/Ubuntu - .NET 8.0

cd ./bin/Release/net8.0
ln -s HelloWorld special_hello
./special_hello

Outputs:

Environment.ProcessPath: /home/xoofx/code/HelloWorld/bin/Release/net8.0/HelloWorld
Environment.GetCommandLineArgs()[0]: /home/xoofx/code/HelloWorld/bin/Release/net8.0/HelloWorld.dll

MacOS/Ubuntu - NativeAOT .NET 8.0

cd ./bin/Release/net8.0/linux-x64/publish
ln -s HelloWorld special_hello
./special_hello

Outputs:

Environment.ProcessPath: /home/xoofx/code/HelloWorld/bin/Release/net8.0/linux-x64/publish/HelloWorld
Environment.GetCommandLineArgs()[0]: ./special_hello

Expected behavior

Environment.GetCommandLineArgs()[0]

This value should always be the strict equivalent of argv[0] in a C/C++ program (and MacOS/Ubuntu - NativeAOT .NET 8.0 is the only one to respect it from the above)

In particular:

• It should not transform to an absolute path or resolve symbolic link
• It should not give a dll whether we are running through corehost from a regular dotnet build

Environment.ProcessPath

From the above it is unclear if:

• It should give an absolute path to the exe name but not following symbolic link? (as on Windows - NativeAOT .NET 8.0) e.g C:\code\HelloWorld\bin\Release\net8.0\win-x64\publish\special_hello.exe
• It should give an absolute path to the fully resolve exe name following symbolic link? (as on MacOS/Ubuntu) e.g /home/xoofx/code/HelloWorld/bin/Release/net8.0/HelloWorld

Implementation problems

I tried to fix it but the problem is that we are not able to recover argv[0] from coreclr_execute_assembly, and I end up hacking argv to actually have argv[0] in it and putting 1 on bit 0 on the pointer to understand behind that it is a special argv, which I conceded is super ugly 😅 (Thinking about it I could hack it more easily by using argc as a negative number to convery that it includes argv[0], but it still ugly 😁 )

int coreclr_execute_assembly(
            void* hostHandle,
            unsigned int domainId,
            int argc,
            const char** argv,
            const char* managedAssemblyPath,
            unsigned int* exitCode)

and while coreclr_initialize receive an exePath (which is not argv[0]), it is processing it to create a commandline string and things get more convoluted here (and it's not used by Environment.GetCommandLineArgs()[0])

int coreclr_initialize(
            const char* exePath,
            const char* appDomainFriendlyName,
            int propertyCount,
            const char** propertyKeys,
            const char** propertyValues,
            void** hostHandle,
            unsigned int* domainId)

I assume that it is not possible to change the signature of these functions?

I would be happy to make a PR, but some guidance regarding coreclr_execute_assembly/coreclr_initialize on how to propagate argv[0] would be appreciated. (If I can add a new arg, that should be relatively easy to fix - but I would have change also e.g CorHost2::ExecuteAssembly)

Thanks! ☺️

cc: @jkotas @MichalStrehovsky @agocke

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[jkotas]

• Consider what the behavior should be for invocation using dotnet host, e.g. dotnet foo.dll. The current behavior of GetCommandLineArgs tries to be consistent between dotnet hello.dll and hello.exe.

• Changing the behavior of GetCommandLineArgs()[0] would need to be treated as a breaking change. For example, code our there can be doing things like AssemblyName.GetAssemblyName(Environment.GetCommandLineArgs()[0]).

• Environment.ProcessPath: We resolve the symlinks on some platforms because we have to in order to return absolute path.

[xoofx]

Consider what the behavior should be for invocation using dotnet host, e.g. dotnet foo.dll. The current behavior of GetCommandLineArgs tries to be consistent between dotnet hello.dll and hello.exe.

Indeed, something I should probably add in the differences.

Changing the behavior of GetCommandLineArgs()[0] would need to be treated as a breaking change. For example, code our there can be doing things like AssemblyName.GetAssemblyName(Environment.GetCommandLineArgs()[0]).

From the above, it looks like Environment.GetCommandLineArgs()[0] is so unspecified that it is barely possible to use it in a consistent manner across NativeAOT/Regular App/Platforms. So I could definitely see some folks relying on it for specific niche cases, but I see also plenty of folks not able to use it because of these inconsistencies (I would personally not use it at all)

If this is not desirable to make a breaking change, would it be not better then to add a new property to Environment, like Environment.Argv0 or something similar? I would make a proposal then. Ideally, I would prefer to introduce a different property for the case of e.g dotnet foo.dll because it would then make Environment.GetCommandLineArgs() the strict equivalent of argv, which is the confusing part today. But if this breaking change is not possible, then we should consider a new property.

Environment.ProcessPath: We resolve the symlinks on some platforms because we have to in order to return absolute path.

The doc says Returns the path of the executable that started the currently executing process. Is there a technical requirement that it should point to the resolved exe?

[jkotas]

it looks like Environment.GetCommandLineArgs()[0] is so unspecified that it is barely possible to use it in a consistent manner across NativeAOT/Regular App/Platforms.

Yes, GetCommandLineArgs()[0] is problematic for single file deployments (that includes NativeAOT). Single file deployments are a niche. Outside of single file deployments, GetCommandLineArgs()[0] always returns the managed binary that started the process.

Is there a technical requirement that it should point to the resolved exe?

It should be an absolute path and it should not be a placeholder like /proc/self/exe.

[xoofx]

Looking at the usage of Environment.GetCommandLineArgs()[0], it is definitely used a lot, so changing it would break too many things. (Not all the usages are expecting a DLL, some are expecting an exe name, but that depends on their usage for sure).

Maybe introducing a new API that would give the additional parts as prefixes would help:

string? Environment.PreCommandLineArg0 would return:

Command line	Environment.PreCommandLineArg0	Environment.GetCommandLineArgs()
./dotnet.exe foo.dll 1 2 3	./dotnet.exe	foo.dll, 1, 2, 3
./foo.exe 1 2 3	./foo.exe	foo.dll, 1, 2, 3
./special_foo.exe 1 2 3 with special_foo.exe symlinked to foo.exe	./special_foo.exe	foo.dll, 1, 2, 3
./special_foo.exe 1 2 3 with special_foo.exe symlinked to foo.exe (NativeAOT)	null	./special_foo.exe, 1, 2, 3

with Environment.PreCommandLineArg0 being the true argv[0] equivalent of C/C++ when it is not covered by Environment.GetCommandLineArgs() for NativeAOT case.

Would that be an acceptable API to resolve this situation?

[xoofx]

Bringing some folks from other issues that would be interested in solving this: @rjmholt, @tmds, @mklement0

[xoofx]

I would be interested maybe in adding also bool Environment.IsImplicitCommandLineArg0 to detect the difference between dotnet.exe foo.dll 1 2 3 and foo.exe 1 2 3 (would be true in that latter with foo.dll being passed implicitly as Environment.GetCommandLineArgs()[0])

[xoofx]

Adding a table for clarity

Command line	?	Environment.PreCommandLineArg0	Environment.GetCommandLineArgs()
./dotnet.exe foo.dll 1 2 3	false	./dotnet.exe	foo.dll, 1, 2, 3
./foo.exe 1 2 3	true	./foo.exe	foo.dll, 1, 2, 3
./special_foo.exe 1 2 3 with special_foo.exe symlinked to foo.exe	true	./special_foo.exe	foo.dll, 1, 2, 3
./special_foo.exe 1 2 3 with special_foo.exe symlinked to foo.exe (NativeAOT)	false	null	./special_foo.exe, 1, 2, 3

with ? = Environment.IsImplicitCommandLineArg0

[jkotas]

I am not following why we would want the API to return null for native AOT.

If we were to add a new API for this, I think it should be a policy-free API that does not change its behavior based on how the process was invoked. Something like: string? Environment.ProcessInvocationName. Returns the name used to invoke the process, same as argv[0] in C/C++, in all situations. Returns null when the invocation name is not available.

[xoofx]

If we were to add a new API for this, I think it should be a policy-free API that does not change its behavior based on how the process was invoked. Something like: string? Environment.ProcessInvocationName. Returns the name used to invoke the process, same as argv[0] in C/C++, in all situations. Returns null when the invocation name is not available.

Indeed, that would work.

(Edit: In that case we would have Environment.IsImplicitCommandLineArg0 true)