Add warning that this isn't how you install .NET Core to run apps.

[KathleenDollard]

User reported confusion using the install scripts to run an app. Tweets are here:

https://twitter.com/zkat__/status/1266151245665861632?s=20
https://twitter.com/zkat__/status/1266432436340092928?s=20

Let's put a comment/warning to use the installers if you want to run .NET Core apps.

I think we just need a simple warning, but I want to preserve @vitek-karas explanation:

---

As far as I can tell dotnet-install.ps1 is not really useful for installing runtimes to be used manually by the user. It’s current behavior:

• It installs to AppData/Local folder by default (I assume to avoid requiring admin rights)
• This location is not registered anywhere after the script is done
• It can (by default it does) append to PATH variable of the current powershell the location it installed to
  • If there’s no .NET Core on the machine (if there already is one, its location will be on PATH before the new install, and thus win)
  • And I use the powershell right after running the sfcript
  • Then it will work – as in typing dotnet.exe will pick the recently installed one
• Once I exit that powershell instance it won’t work on its own. I have to add the location to PATH myself. Note that the script prints out the location in relatively unfriendly way:
  dotnet-install: Adding to current process PATH:

"C:\Users\vitkaras\AppData\Local\Microsoft\dotnet\". 

Note: This change will not be visible if PowerShell was run as a child process.

What can we do about it:

• We should make it at least consistent. So when the script sets PATH it should also set DOTNET_ROOT accordingly (unless it’s already set?)
• Make it at least possible to install to global locations with the script – would require admin rights though
• Print out a good description what the user needs to do, to correctly register the new location – set it on PATH and DOTNET_ROOT.

Detailed explanation of what happens and why when running global tools:

Global tools are always executables, and they were basically the first widely used thing which used executables in .NET Core (before 2.1 we didn’t have the ability to produce executables and everything had to be executed via dotnet.exe).

We made a conscious decision to NOT parse PATH in the .NET Core executable (it’s HARD). So when one runs “dotnet.exe” the PATH resolution is done by the OS/CommandLine, once started dotnet.exe looks at two locations – the place where it is running from and the “global” location.

Application executable can’t look at the place where it’s running from (there’s nothing there, just the app), so it has to rely on something else. That something else is “DOTNET_PATH” environment variable. After that it also looks at “global” location.

“global” location is by default program files.

The dotnet-install.ps1 can set PATH, but it never sets DOTNET_ROOT. I don’t know why. That said regardless of what it does, it would only have effect when running apps after running dotnet-install.ps1 from the same powershell window.

To make the “private” install accessible from anywhere, the user has to add its location to PATH (in user profile or system wide) manually (I assume that’s what you did @kat ?). To make the global tools work the user would have to set DOTNET_ROOT env. variable (in the user profile or system wide).

---

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: a2e484a9-5e0c-eb3e-1413-7b507c4fa07d
• Version Independent ID: 5bc7caa5-f1c2-d7d5-fe02-80c65cca9672
• Content: dotnet-install scripts - .NET Core CLI
• Content Source: docs/core/tools/dotnet-install-script.md
• Product: dotnet-core
• Technology: dotnet-cli
• GitHub Login: @tdykstra
• Microsoft Alias: tdykstra

[tdykstra]

Let's put a comment/warning to use the installers if you want to run .NET Core apps.

What then should we say are the valid use cases for the install scripts?

[vitek-karas]

I know about one but I think the authors of the script should chime in on it.

• The script is used by all our repos to install repo-local .NET Core SDK which is then used to build the repo in question. (also used in CI for the same purpose)

[tdykstra]

@vitek-karas

the authors of the script should chime in on it

Who are the authors?

[vitek-karas]

The scripts originate from here https://github.com/dotnet/install-scripts I think. I created dotnet/install-scripts#43 to get the attention of the right people.

[bekir-ozturk]

In my opinion, the valid case to use the scripts is:

• Installing the SDK during CI without user interaction and without admin rights. Installation is not meant to be persistent across multiple CI runs: CI triggers -> SDK installed -> CI complete -> machine data cleared.

There are already many different options for installing the SDK (installers, package managers, containers etc.) which cover a great deal of use cases. We would like to keep scripts separate from those and focus on the main use case: CI. (any disagreements here? @KathleenDollard )

I don't mean "scripts shouldn't set DOTNET_ROOT". Bu putting a warning in the docs and in the script as a first step sounds like a good idea to me. We will track the issue related to the warning printed by the scripts here: dotnet/install-scripts#47