Respect DOTNET_CLI_HOME for .NET Core SDK 2.1.4xx

[peterhuene]

Details about Problem

In 2.1.3xx of the .NET Core SDK, dotnet <command> crashes if HOME is unset on macOS and Linux or USERPROFILE is unset on Windows. It is quite common for HOME not to be set on CI machines.

This has been fixed in the release/2.1.4xx branch of the CLI (see https://github.com/dotnet/cli/issues/8053 and dotnet/cli#9327). The CLI now respects a variable named DOTNET_CLI_HOME that can be set to only affect dotnet without affecting any other programs. If the variable is not set, it falls back to HOME/USERPROFILE and, if that variable isn't set, errors with the following message:

The user's home directory could not be determined. Set the 'DOTNET_CLI_HOME' environment variable to specify the directory to use.

Because many of dotnet's commands rely on NuGet, users are unable to run the commands without HOME set because NuGet will crash:

$ DOTNET_CLI_HOME=/tmp dotnet restore
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018: The "WarnForInvalidProjectsTask" task failed unexpectedly. [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018: System.InvalidOperationException: Required environment variable 'HOME' is not set. Try setting 'HOME' and running the operation again. [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at NuGet.Common.NuGetEnvironment.GetValueOrThrowMissingEnvVar(Func`1 getValue, String name) [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at NuGet.Common.NuGetEnvironment.GetHome() [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at NuGet.Common.NuGetEnvironment.<>c.<.cctor>b__12_0() [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode) [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor) [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at System.Lazy`1.CreateValue() [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at NuGet.Common.NuGetEnvironment.GetFolderPath(SpecialFolder folder) [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at NuGet.Common.NuGetEnvironment.GetFolderPath(NuGetFolderPath folder) [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at NuGet.Common.PathUtility.CheckIfFileSystemIsCaseInsensitive() [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode) [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor) [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at System.Lazy`1.CreateValue() [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at NuGet.Common.PathUtility.GetStringComparerBasedOnOS() [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at NuGet.Build.Tasks.WarnForInvalidProjectsTask.Execute() [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [/home/peterhu/tmp/blah/blah.csproj]
/home/peterhu/src/cli/bin/2/linux-x64/dotnet/sdk/2.1.400-preview-008942/NuGet.targets(264,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [/home/peterhu

System Information

$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.1.400-preview-008931
 Commit:    8f8770be8a

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.13
 OS Platform: Darwin
 RID:         osx.10.13-x64
 Base Path:   /Users/peterhuene/src/cli/bin/2/osx-x64/dotnet/sdk/2.1.400-preview-008931/

Host (useful for support):
  Version: 2.1.0-rtm-26515-03
  Commit:  caa7b7e2ba

.NET Core SDKs installed:
  2.1.400-preview-008931 [/Users/peterhuene/src/cli/bin/2/osx-x64/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0-rtm-30752 [/Users/peterhuene/src/cli/bin/2/osx-x64/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0-rtm-30752 [/Users/peterhuene/src/cli/bin/2/osx-x64/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.0-rtm-26515-03 [/Users/peterhuene/src/cli/bin/2/osx-x64/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Repro steps

1. dotnet new console

2. On Linux/macOS, unset HOME.

3. If running 2.1.3xx of the CLI, this can be observed with HOME='' dotnet restore. If running 2.1.4xx of the CLI, this can be observed with DOTNET_CLI_HOME=/tmp dotnet restore.

Note: the 2.1.3xx command above will create a .dotnet directory in the current working directory (also fixed in 2.1.4xx).

Expected results

If DOTNET_CLI_HOME is set, respect it and use it instead of HOME.

If DOTNET_CLI_HOME is not set, print out a friendlier error instead of the unhandled InvalidOperationException notifying users that the user's home directory could not be determined (similiar to what 2.1.4xx of the CLI now prints).

Actual results

NuGet crashs (see output above) and the dotnet command fails. Many of the dotnet commands aren't usable without HOME set.

[nkolev92]

Could this easily lead to an experience where a user ends up with multiple global packages folder?

Should NuGet warn anytime it uses DOTNET_CLI_HOME instead of the user's home directory?
This will affect config discovery too, which would lead to a funny experience.

Might be a basic question, but what's a true prod example where the $HOME is not set?

//cc
@rrelyea

[peterhuene]

I think warning the user that DOTNET_CLI_HOME is being respected isn't a bad idea; we could certainly add that to the CLI too.

A production example is Azure/VSTS where some services aren't running as a user with a home directory. Most recently was today with VSTS trying to install 2.1.300 as such a user and failing during first-run experience for dotnet.

I'm sure there are CI vendors out there that might not run their service as a user with HOME set either.

[nkolev92]

Would dotnet always catch any irregularities with the HOME/DOTNET_CLI_HOME variables prior to calling NuGet?

Say, if we condition this to work only for .NET Core, would NuGet ever get to the place where it's the one failing?

[peterhuene]

It shouldn't because the CLI will check for either one to be set prior to invoking any dotnet commands (including dotnet nuget).

[nkolev92]

The reason I was asking that is, that probably the CLI should then emit a/the warning.

Especially since this is a special scenario, the noise wouldn't be too bad.
We would ofc need to summarize the behavior when this happens because the global packages folder/caching/config discovery and plugin discovery would change.

[peterhuene]

I'm onboard with having the CLI emit a warning, with perhaps a mechanism to suppress it for CI environments that don't want the warning logged in their console output upon every dotnet invocation.

[nkolev92]

Sounds good.
I'll sync up with you when I get around to this bug.