On environments where registry access is disabled, the first run experience
fails because it could not add the tools path to the user's environment.
This fix properly handles the security exception by printing a warning and
continuing. Users will have to manually add the PATH environment variable to
their environments to prevent `dotnet tool install` from printing PATH
instructions.
A new file sentinel is added to track whether or not the PATH has been
modified. The first run experience also now correctly skips modifying the PATH
if `DOTNET_SKIP_FIRST_TIME_EXPERIENCE` is set.
Fixes#8874.
Environment.GetEnvironmentVariable(PathName) means
Environment.GetEnvironmentVariable(PathName,
EnvironmentVariableTarget.Process)
However, I have added to .User. So the detection of path existence
failed. And it ends up adding the path again and again
* compose all the parts
* Fix on obtain and shim maker for better end to end experience
* Fix error when there is space in the middle of path of nuget config
* Fix path in profile.d is the tmp home path during install
* better handle of ~home
* remove profile.d file in uninstall script
* Fix test since it looks up current directory
* folder structure inside nupkg to tools/TFM/RID/mytool.dll
* Add check for config file existence
* Rename name space to Microsoft.DotNet.ShellShim
* Rename name space to Microsoft.DotNet.ToolPackage
2017-12-04 14:13:24 -08:00
Renamed from src/dotnet/ShellShimMaker/EnvironmentPathFactory.cs (Browse further)
