Could not re-locate .dotnet\NuGetFallbackFolder to any other location

[ksivasenthil]

Intent / Goal

Relocate the nuget packages downloaded in %USERPROFILE% directory to a drive other than OS installation.

Steps to reproduce

1. Edit the NuGet.config file located @ %APPDATA%\NuGet to change the value attribute for packageSource with key "CliFallbackFolder" to a location other than %USERPROFILE%.dotnet\NuGetFallbackFolder. In my case I used D:\dotnet\NuGetFallbackFolder.
2. Set the user environment variable "DOTNET_CLI_TEST_FALLBACKFOLDER" to the same location that was set in Step 1 above i.e. D:\dotnet\NuGetFallbackFolder.
3. Create a 0 kb file with name "2.0.0-preview2-006497.dotnetSentinel" inside the folder mentioned D:\dotnet\NuGetFallbackFolder.
4. Set the user environment variable "DOTNET_SKIP_FIRST_TIME_EXPERIENCE" to 1.
5. Create a new dotnet project on a folder "HelloWorld" by issuing the command
   a. mkdir %USERPROFILE%\HelloWorld
   b. cd %USERPROFILE%\HelloWorld
   c. dotnet new console --language C#

Expected behavior

Assemblies required for dotnet to execute should be cached to location mentioned in Step 1 & 2.

Actual behavior

Assemblies required for dotnet cli to work are cached to %USERPROFILE%.dotnet\NuGetFallbackFolder

Environment data

dotnet --info output:
.NET Command Line Tools (2.0.0-preview2-006497)

Product Information:
Version: 2.0.0-preview2-006497
Commit SHA-1 hash: 06a2093

Runtime Environment:
OS Name: Windows
OS Version: 6.1.7601
OS Platform: Windows
RID: win7-x64
Base Path: C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\

Microsoft .NET Core Shared Framework Host
Version : 2.0.0-preview2-25407-01
Build : 40c565230930ead58a50719c0ec799df77bddee9

##Notes
Couple of observations based on code -

1. Microsoft.DotNet.Cli.Program.ConfigureDotNetForFirstTimeUse method uses the Microsoft.DotNet.Configurer.FirstTimeUseNoticeSentinel (type of Microsoft.DotNet.Configurer.IFirstTimeUseNoticeSentinel) which is initialized with
   CliFallbackFolderPathCalculator.DotnetUserProfileFolderPath.

2. Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure method after relevant checks
   calls the Microsoft.DotNet.Configurer.NuGetCachePrimer.PrimeCache which uses the CliFallbackFolderPathCalculator.CliFallbackFolderPath.

3. To avoid clogging the OS drive I also tried to short circuit the first time download of NuGet packages to cache using the steps mentioned above. However, I noticed while reading environment variable in Microsoft.DotNet.Cli.Utils.EnvironmentProvider.GetEnvironmentVariableAsBool method, EnvironmentVariableTarget is not considered. Microsoft.DotNet.Cli.Utils.EnvironmentProvider.GetEnvironmentVariableAsBool method called as part of the checks performed @ Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.ShouldPrimeNugetCache validation method called from the Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure method.

%USERPROFILE%.dotnet\NuGetFallbackFolder getting populated

Relocated NuGetFallbackFolder remains empty

[livarcocc]

In preview3, we no longer use NuGet.Config. DOTNET_CLI_TEST_FALLBACKFOLDER is also available only in preview3 and is meant to be used as a test tool only, that's why TEST is in the name. So, if you depend on it, there is no real guarantee that it will continue to be available.

[ksivasenthil]

Thank you @livarcocc. I tried the DOTNET_CLI_TEST_FALLBACKFOLDER environment variable only in desperation.

Is there any way the goal (Relocate the nuget packages downloaded in %USERPROFILE% directory to a drive other than OS installation.) could be achieved with net core 2.0.0-preview2-006497?

[livarcocc]

If you mean the nuget local user cache, you can use an environment variable called NUGET_PACKAGES. You can also set that in your NuGet.Config file. But I don't remember the exact name of the element there.

If you intend to change the CLI offline cache location, I wouldn't recommend doing that. There is no way to do that and for the product to continue to work. You need to think of that offline cache as part of the overall SDK.

If you want to do that, I would recommend trying to move the whole SDK to this other drive.