Fix Environment.GetCommandLineArgs()[0] to report the host invocation name

[xoofx]

Hello .NET runtime folks, ☺️

Back on the topic to try to fix #101837. I have used ChatGPT 5.6 Sol with guidance from the issue, my previous hacky PR and safest path analysis.

Summary

Environment.GetCommandLineArgs()[0] currently reports the managed assembly path, or the resolved bundle path for single-file applications, rather than the name used to invoke the native host. This is especially visible when an apphost is launched through a symbolic link.

For apphost launches, this change preserves the native host's original argv[0] and uses it only for element zero of the array returned by Environment.GetCommandLineArgs(). The dotnet muxer continues to use the managed application path for element zero, and all remaining elements retain their existing behavior.

Implementation

• Adds the well-known ARGV0 host runtime property.
• Captures the apphost argv[0] in hostpolicy before host-mode argument parsing.
• Queries the property from CoreCLR when initializing the managed command-line array.
• Retains the existing assembly/bundle-path fallback when a host does not provide the property.
• Documents the new host runtime property.

The complete native argument vector is intentionally not preserved or exposed. The resulting behavior is:

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

This does not change:

• Managed Main arguments
• Environment.ProcessPath
• Bundle probing or resolution
• Native hosting API signatures
• The meaning of exePath
• Behavior for hosts that do not implement the new property

Testing

• Built Checked CoreCLR.
• Built the libraries and Checked host components/host tests.
• Ran the focused muxer command-line test and all 19 HostActivation.Tests.SymbolicLinks tests successfully.
• Manually verified the resulting command-line arrays with both dotnet and corerun.

The symbolic-link test verifies that element zero retains the original apphost invocation path while element one remains the existing managed argument.

Note

This PR description was drafted with AI assistance.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR changes Environment.GetCommandLineArgs()[0] on CoreCLR to reflect the native host invocation name (argv[0]) when available, instead of the managed assembly (or single-file bundle path), by flowing the invocation name from the host to the runtime via a new host runtime property.

Changes:

• Add a new well-known host runtime property (HOST_INVOCATION_NAME) and plumb it through hostpolicy to CoreCLR.
• Update CoreCLR command-line initialization to prefer HOST_INVOCATION_NAME for element 0 (with existing fallbacks).
• Extend HostActivation symbolic-link testing (and the HelloWorld test asset) to validate the new behavior.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/native/corehost/hostpolicy/hostpolicy_context.h	Stores host invocation name in the hostpolicy context.
src/native/corehost/hostpolicy/hostpolicy_context.cpp	Serves HOST_INVOCATION_NAME via get_runtime_property and initializes it from parsed args.
src/native/corehost/hostpolicy/args.h	Adds invocation_name to the parsed arguments model.
src/native/corehost/hostpolicy/args.cpp	Captures argv[0] as the invocation name before host-mode argument parsing.
src/native/corehost/host_runtime_contract.h	Defines the HOST_PROPERTY_INVOCATION_NAME key.
src/coreclr/vm/corhost.cpp	Uses HostInformation::GetProperty(HOST_INVOCATION_NAME, …) to set Environment.GetCommandLineArgs()[0].
src/coreclr/hosts/corerun/corerun.cpp	Provides HOST_INVOCATION_NAME from corerun and captures its argv[0].
src/installer/tests/HostActivation.Tests/SymbolicLinks.cs	Asserts that [0] preserves the apphost invocation path and [1] remains the first managed arg.
src/installer/tests/Assets/Projects/HelloWorld/Program.cs	Adds a test hook to print Environment.GetCommandLineArgs() for verification.
docs/design/features/host-runtime-information.md	Documents the new HOST_INVOCATION_NAME property.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/native/corehost/hostpolicy/hostpolicy_context.cpp:131

• HOST_INVOCATION_NAME is surfaced unconditionally for non-libhost modes. If argv[0] is empty (which is legal on some platforms/launchers), this would make the property appear present and cause Environment.GetCommandLineArgs()[0] to become an empty string rather than falling back to the assembly/bundle path. Consider treating an empty invocation_name as "not found" by returning -1 in that case as well.

        if (::strcmp(key, HOST_PROPERTY_INVOCATION_NAME) == 0)
        {
            if (context->host_mode == host_mode_t::libhost)
                return -1;

            return pal::pal_utf8string(context->invocation_name, value_buffer, value_buffer_size);
        }

src/coreclr/hosts/corerun/corerun.cpp:295

• If corerun is launched in an unusual way where argv[0] is the empty string, this implementation would report HOST_INVOCATION_NAME as present (length 1) and CoreCLR would then use an empty string for Environment.GetCommandLineArgs()[0]. Consider returning -1 when invocation_name is empty so the runtime can fall back to the existing bundle/assembly behavior.

    if (::strcmp(key, HOST_PROPERTY_INVOCATION_NAME) == 0)
    {
        pal::string_utf8_t value_utf8 = pal::convert_to_utf8(config->invocation_name.c_str());
        size_t len = value_utf8.size() + 1;
        if (value_buffer_size < len)
            return len;

        ::strncpy(value_buffer, value_utf8.c_str(), len - 1);
        value_buffer[len - 1] = '\0';
        return len;
    }

[jkotas]

The complete native argument vector is intentionally not preserved or exposed. For example:

dotnet app.dll arg

now produces an Environment.GetCommandLineArgs() array equivalent to:

[ "dotnet", "arg" ]

I do not think that this is the behavior we want.

IIRC, the desired behavior we have discussed is captured in this table #101837 (comment)

[xoofx]

Fixed via 6ef8b95

Note

This comment was generated with AI assistance.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.

Suppressed comments (1)

docs/design/features/host-runtime-information.md:45

• The new property description is a bit ambiguous about what happens when running via the dotnet muxer. Since the muxer doesn’t provide HOST_INVOCATION_NAME (per this doc and the updated tests), it may help to add an explicit example so readers don’t infer that dotnet app.dll arg will make GetCommandLineArgs()[0] become dotnet.

`HOST_INVOCATION_NAME`

The name used to invoke an application host, corresponding to the native process's `argv[0]`. The apphost and `corerun` hosts provide this property for the first element returned by [`Environment.GetCommandLineArgs()`](https://learn.microsoft.com/dotnet/api/system.environment.getcommandlineargs). The `dotnet` muxer does not provide this property, preserving the managed application path as the first element.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/native/corehost/hostpolicy/args.cpp:24

• The new argc > 0 guard suggests apphost could be invoked without argv[0], but the rest of this function unconditionally assumes apphost has at least one argument (&argv[1], argc - 1). To avoid a misleading partial guard, either validate/return false for invalid inputs, or assert the invariant and always capture argv[0] in apphost mode.

    if (init.host_mode == host_mode_t::apphost && argc > 0)
        args.invocation_name = argv[0];

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

[jkotas]

This looks good to me, modulo the naming nit. @elinor-fung ?

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (1)

docs/design/features/host-runtime-information.md:46

• The new ARGV0 property entry doesn’t indicate which .NET version introduced it. Elsewhere in this doc, newly added properties include an explicit “Added in .NET X” note (for example BUNDLE_EXTRACTION_PATH). Without a version marker, readers may incorrectly assume ARGV0 has existed since the original .NET 8 host runtime contract.

`ARGV0`

The name used to invoke an application host, corresponding to the native process's `argv[0]`. The apphost provides this property for the first element returned by [`Environment.GetCommandLineArgs()`](https://learn.microsoft.com/dotnet/api/system.environment.getcommandlineargs). Muxer-style hosts, including `dotnet` and `corerun`, do not provide this property, preserving the managed application path as the first element.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/native/corehost/hostpolicy/args.cpp:28

• The new apphost branch asserts argc/argv are valid, but in release builds the assert is compiled out and argv[0] will be dereferenced unconditionally. If a host ever calls into hostpolicy with an unexpected argc/argv (or argv[0] null), this becomes an immediate crash. Prefer a defensive runtime check (and fail parsing) instead of relying on assert-only validation.

    if (init.host_mode == host_mode_t::apphost)
    {
        assert(argc > 0 && argv != nullptr);
        args.invocation_name = argv[0];

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/native/corehost/hostpolicy/hostpolicy_context.cpp:131

• HOST_PROPERTY_ARGV0 is intended to reflect the native argv[0], but the current check treats an empty invocation name as “property not provided” and falls back to the assembly/bundle path. An empty argv[0] is a valid (if rare) scenario on Unix, so this conflates “not provided” with “provided but empty” and can produce an incorrect fallback value. Consider using host_mode to decide whether the property is supported, and return the (possibly empty) string when running under apphost.

        if (::strcmp(key, HOST_PROPERTY_ARGV0) == 0)
        {
            if (context->invocation_name.empty())
                return -1;

            return pal::pal_utf8string(context->invocation_name, value_buffer, value_buffer_size);
        }

[elinor-fung]

Thank you!

[elinor-fung]

/ba-g #131805

[eerhardt]

Should this be tagged as a breaking change (and get a breaking-change doc)? It changed observable behavior for apphost-launched apps in .NET 11.

We hit this in Aspire after retargeting our CLI to net11.0. Our tests run through the Microsoft.Testing.Platform apphost, and System.CommandLine derives the root command name from Path.GetFileNameWithoutExtension(Environment.GetCommandLineArgs()[0]):

• .NET 10: args[0] was .../Aspire.Cli.Tests.dll, so the name was Aspire.Cli.Tests on every OS.
• .NET 11: args[0] is the apphost. On Windows that's Aspire.Cli.Tests.exe, which still gives Aspire.Cli.Tests. On Linux/macOS it's the extension-less Aspire.Cli.Tests, so the name becomes Aspire.Cli, because .Tests is treated as the extension.

As a result, help-output snapshots started failing only on Linux/macOS (microsoft/aspire#20436). Anything else that uses args[0] to locate the app's .dll, or derives a name from it, would see the same change, so a note in the .NET 11 breaking changes docs seems worthwhile.

I've opened a related issue on System.CommandLine that broke because of the change: dotnet/command-line-api#2850