-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dotnet run command should set DOTNET_ROOT environment variable #9866
Comments
I'm trying to envision scenarios that break if we always set I need a refresher on the fallback logic that happens when 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 |
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. |
Unlike last time in 2.1, we have some time to adjust in 3.0. I would support making |
I'm good with that plan. |
Note: This should set |
I'm going to fix this now to get the CLI tests green. |
#Repro steps
dotnet new console
)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
, anddotnet run
uses that apphost. Previously it useddotnet <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 indotnet 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 adotnet
command. In the past we've discussed that probing thePATH
from the muxer could help, but so far have decided against it.FYI @natemcmaster @peterhuene
The text was updated successfully, but these errors were encountered: