Sdk: dotnet run command should set DOTNET_ROOT environment variable

[dsplaisted]

Repro steps

• Install a local copy of the .NET Core SDK (ie unzip it to a local folder, or install it to a local folder using the dotnet-install script)
• Create a new console app (dotnet new console)
• Run the app via dotnet run

Expected

App runs

Actual

Host can't find the right shared framework (unless a matching shared framework is also installed in the global location, such as Program Files).

Discussion

This is because we now copy the apphost as <appname>.exe, and dotnet run uses that apphost. Previously it used dotnet <appname>.dll, which had the context of where the dotnet root was, but the apphost by itself doesn't have that context, so it only looks in the globally installed location.

We can fix this by setting the DOTNET_ROOT environment variable in dotnet run before launching the app. We could also consider always setting this environment variable, which we considered in the past.

These solutions still won't help if <appname>.exe is launched directly instead of via a dotnet command. In the past we've discussed that probing the PATH from the muxer could help, but so far have decided against it.

FYI @natemcmaster @peterhuene

[peterhuene]

I'm trying to envision scenarios that break if we always set DOTNET_ROOT (if not already set) from dotnet run.

I need a refresher on the fallback logic that happens when DOTNET_ROOT is set.

Is it an additional probing location or an authoritative one?

That is to say, if I have a 2.1 runtime installed globally, download a 3.0 SDK to a non-default location to use it to build and run a 2.1 targeting app, will dotnet run setting DOTNET_ROOT break the running of the app despite a compatible runtime being present?

[nguerrera]

So it turns out that on Windows, it will still do the multilevel lookup to the global location as a fallback. On Unix, DOTNET_ROOT would just be a complete hammer that overrides the global location. The concerns I raised still apply in general. I think dotnet should be able to append its location as a probing path without altering any other probing paths for runtimes. The host does not have this capability today, but we should ask for it again IMHO.

[nguerrera]

Unlike last time in 2.1, we have some time to adjust in 3.0. I would support making dotnet run set DOTNET_ROOT for now and discussing better alternatives. It is not as invasive as setting it for all builds, for example.

[peterhuene]

I'm good with that plan.

[dsplaisted]

Note: This should set DOTNET_ROOT(x86) instead if the version of .NET is x86

[peterhuene]

I'm going to fix this now to get the CLI tests green.

[agawasare]

Please see https://dotnetresolutions.wordpress.com/2020/05/21/making-net-core-binaries-work-with-visual-studio-code