Have child processes use the same runtime as parent process

[steveharter]

When a child framework-dependent apphost is launched today, it may not find the same framework that was used to launch it, or it may not find any framework at all.

To address this, a plan currently under review is to leverage the %DOTNET_ROOT% environment variable that was added in dotnet/core-setup#3888.

The additional detail below is preliminary pending design review:

This feature will set the environment variable for the current process, which will extend to child processes and be used to find the same runtime as the parent.

This environment variable at the global (or current environment) level is not set by our installers or by any (known) scripts. It is there for the user to set if the default install location does not work for framework-dependent apphost scenarios. However, this new feature sets the environment variable for the currently running dotnet.exe\apphost to allow child processes when launched to use the same runtime.

This helps replace current one-off implementations that may try one of several ways to find a runtime including the CLI's %DOTNET_HOST_PATH%, default install location, or the dotnet.exe found in %PATH%. Now when launching a dotnet.exe child process directly, the parent process can leverage DOTNET_ROOT. If launching a child apphost, the apphost will detect DOTNET_ROOT and look there for the runtime.

The current requirements:
• For dotnet.exe, DOTNET_ROOT is always set to the directory that contains the currently running dotnet.exe.
• For framework-dependent apphost.exe, DOTNET_ROOT is set to the location of the root of the parent dotnet directory that contains hostfxr.*
• For self-contained apphost.exe, DOTNET_ROOT is not set or used. A self-contained application does not need to find the runtime because it is local. The existing DOTNET_ROOT value is passed through.
• No multi-level lookup when DOTNET_ROOT is set. Multi-level lookup is a Windows feature where we pick the "most compatible" framework or SDK from %ProgramFiles% in addition to the current hive where dotnet.exe or apphost is running from, instead of just the current hive.

Note that for x86 applications running under Wow64, DOTNET_ROOT(x86) will be used instead. It is likely that both DOTNET_ROOT and DOTNET_ROOT(x86) will both be set in mixed 32- and 64-bit environments.

cc @jaredpar @richlander

[jkotas]

I do not think that dotnet.exe host should be setting DOTNET_ROOT environment variable by default. You cannot tell in general case whether the child processes launched by the current process (and the processed launched by those processes) are part of the same dotnet chain; or whether they are starting a different chain that should just use the global defaults. Setting it by default breaks about as many cases as it fixes in the general case.

I think we need an API to find the path to the "current" dotnet.exe if there is one, so that folks do not have to find it in ad-hoc way like ManagedToolTask. This is part of the more general problem that we have no public APIs today to find basic information about your .NET execution environment, like what runtime version are you running on.

Once we have API like this, tools like msbuild that wish to force all child processes launched by them to use same runtime can set the DOTNET_ROOT environment variable.

[steveharter]

Closing this issue for 2.1 @richlander @nguerrera @livarcocc @jaredpar

Summary of last discussion:

• For 2.1: Framework-dependent exes will honor DOTNET_ROOT (as they do currently)
• For next release, we will consider:
  o Accept a new parameter on apphost that specifies the dotnet location to use (basically the same as DOTNET_ROOT but on the command line)
  o Setting an EV (maybe DOTNET_HOST_PATH) for the location of the root of the current dotnet install, as informational only
  o Exposed an API for the same thing