Make dotnet --info print all DOTNET_* environment variables

[elinor-fung]

dotnet --info currently only prints DOTNET_ROOT / DOTNET_ROOT_<ARCH> if they are set. Expand it to all environment variables with a DOTNET_ or COREHOST_ prefix.

Example:

Environment variables:
  COREHOST_TRACE                           [1]
  COREHOST_TRACEFILE                       [trace.log]
  DOTNET_ROLL_FORWARD                      [Major]
  DOTNET_ROOT                              [C:\repos\runtime\.dotnet]
  DOTNET_SKIP_FIRST_TIME_EXPERIENCE        [1]

Resolves #117732

cc @dotnet/appmodel @AaronRobinsonMSFT @richlander

[Copilot]

Pull Request Overview

This PR enhances the dotnet --info command to display all environment variables with DOTNET_ or COREHOST_ prefixes, rather than only showing DOTNET_ROOT related variables. The implementation adds cross-platform environment variable enumeration functionality and updates the output formatting to accommodate longer variable names.

Key changes:

• Adds platform-specific environment variable enumeration functions
• Updates environment variable filtering and display logic to include all DOTNET_* and COREHOST_* variables
• Replaces existing targeted test with comprehensive test coverage for the new functionality

Reviewed Changes

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

Show a summary per file

File	Description
src/native/corehost/hostmisc/pal.h	Adds function declaration for enumerate_environment_variables with functional header include
src/native/corehost/hostmisc/pal.windows.cpp	Implements Windows-specific environment variable enumeration using GetEnvironmentStringsW
src/native/corehost/hostmisc/pal.unix.cpp	Implements Unix-specific environment variable enumeration using extern environ
src/native/corehost/fxr/install_info.cpp	Refactors environment variable display logic to enumerate, filter, sort, and display all DOTNET_/COREHOST_ variables
src/installer/tests/HostActivation.Tests/InstallLocation.cs	Removes old test that only tested DOTNET_ROOT variables
src/installer/tests/HostActivation.Tests/HostCommands.cs	Adds comprehensive test for new environment variable enumeration functionality

[Copilot]

The extern declaration should be moved to the top of the file with other includes, or use the standard #include <unistd.h> which declares environ on most systems.

Suggested change

extern char **environ;

[dotnet-policy-service]

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

[reflectronic]

Should it show COMPlus_ environment variables?

Should the prefix match be case-insensitive on Windows?

[agocke]

The COMPlus names are legacy that we’d like to phase out. I don’t think we should add support for them in new features.

[rhuijben]

Can we somehow just show what is used instead of just showing all environment variables a simple shell script could do?
That way it would be a tool to see which variables are folded into each other instead of just a simple trace of wat is set.

I would guess the answer is no, as multiple layers look at different env vars...

[richlander]

Do you mean which were honored at runtime? That seems more like the responsibility of a tracing system.

Do you have a specific use case?

[am11]

The COMPlus names are legacy that we’d like to phase out.

In the same vein, introducing a DOTNET_ prefix for COREHOST_* and phasing out the non-prefixed versions sounds like a solid next step toward consistency. (we also have some undocumented-but-working-in-prod PAL_* env vars floating around, like PAL_MAP_READONLY_PE_HUGE_PAGE_AS_SHARED 🤯)

[richlander]

Good idea @am11: #117797 (comment)

Yes, let's make this feature specific to DOTNET_ only.

As Andy suggests, this make it clear that they are our only supported ENVs. It's our public namespace. LLMs are going to make the assumption that DOTNET_ is a .NET ENV and are likely to get confused about all these other wonky ones. We can narrow the signal.

[reflectronic]

There are a number of variables that begin with CORECLR_ used for profiling as well. https://learn.microsoft.com/en-us/dotnet/core/runtime-config/debugging-profiling

this make it clear that they are our only supported ENVs.

I don't see how this makes it clear. What is clear that the COMPlus_ prefix is documented for many options (example), and that you claim these variables "will continue to work." If these options are actually unsupported then hiding them from this diagnostics panel does not make that clear.

[richlander]

My take is that teams can move to use DOTNET_ if they'd like. We're only going to honor from scheme here.

@noahfalk

[am11]

If these options are actually unsupported then hiding them from this diagnostics panel does not make that clear.

The rationale behind introducing the DOTNET_ prefix (while retaining COMPlus_ as a fallback for compatibility) is to encourage a gradual transition. Many existing docs now primarily reference DOTNET_ variables, so over time, users will adopt the new prefix. This approach allows the .NET team to consolidate ownership of a single prefix namespace. In mixed production environments with multiple tech stacks, filtering by prefixes like DOTNET_*, JAVA_*, etc., becomes straightforward and consistent.

[noahfalk]

Supporting DOTNET variations of the ICorProfiler env vars seems like a good thing to do at some point. I filed #117902 to track it.