Failed to create prime the NuGet cache. new failed with: -2147352571

[ericwj]

Steps to reproduce

Install 2.0.0-preview1 SDK

nuget locals all -clear
mkdir sln | cd
@{ sdk = @{ version = "1.0.1" } } | ConvertTo-Json | Out-File -FilePath global.json -Encoding utf8
mkdir app | cd
dotnet new console
dotnet restore

Expected behavior

The package cache is populated.
The restore succeeds.
Subsequent restores are fast.

Actual behavior

The package cache is decompressed and expanded, but then fails:

Failed to create prime the NuGet cache. new failed with: -2147352571

The restore succeeds, but it takes about 45 seconds every time.

I think the error message also suffers a correction without having removed the corrected verb. It'd probably be either create or prime, but not both.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.1

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview1-002028-00
  Build    : 6d0caecf154d3398b9bc0e637089b6af9e250479

PS C:\...\src\Project> gc ..\..\global.json
{
  "sdk": {
    "version": "1.0.1"
  }
}

The error is in fact 0x80020005 (Access denied) but the same thing happens running this from an elevated PowerShell terminal.
Removing the preview SDK, the cache is primed again properly on first try.
I haven't tried this (yet) on any other 2.0.0-* SDK other than the nightly mentioned. I'll probably download a newer one once I'll need 2.0 again.

[livarcocc]

@mlorbetske can you take a look at this one? Seems like dotnet new in the command failing with access denied.

[mlorbetske]

@livarcocc I can repro this with the 1.0.1 CLI & running through Powershell but not with the 2.0 CLI running through Powershell. Still investigating.

[mlorbetske]

@livarcocc actually - it seems that VS had locked an assembly in the package cache (%userprofile%.nuget\packages\system.runtime\4.3.0\ref\netstandard1.5\System.Runtime.dll) causing the restore to fail. Running the script above produces the following with the lock released

PS C:\Users\mlorbe> dotnet nuget locals all --clear
>> mkdir sln | cd
>> @{ sdk = @{ version = "1.0.1" } } | ConvertTo-Json | Out-File -FilePath global.json -Encoding utf8
>> mkdir app | cd
>> dotnet new console
>> dotnet restore
info : Clearing NuGet HTTP cache: C:\Users\mlorbe\AppData\Local\NuGet\v3-cache
info : Clearing NuGet global packages cache: C:\Users\mlorbe\.nuget\packages\
info : Clearing NuGet Temp cache: C:\Users\mlorbe\AppData\Local\Temp\NuGetScratch
info : Local resources cleared.

Welcome to .NET Core!
---------------------
Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.

Telemetry
--------------
The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include command-line arguments. The data is collected by Microsoft and shared with the community.
You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry.

Configuring...
-------------------
A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.
Decompressing 100% 4380 ms
Expanding 100% 6871 ms
Content generation time: 58.6965 ms
The template "Console Application" created successfully.
  Restoring packages for C:\Users\mlorbe\sln\app\app.csproj...
  Generating MSBuild file C:\Users\mlorbe\sln\app\obj\app.csproj.nuget.g.props.
  Generating MSBuild file C:\Users\mlorbe\sln\app\obj\app.csproj.nuget.g.targets.
  Writing lock file to disk. Path: C:\Users\mlorbe\sln\app\obj\project.assets.json
  Restore completed in 883.64 ms for C:\Users\mlorbe\sln\app\app.csproj.

  NuGet Config files used:
      C:\Users\mlorbe\AppData\Roaming\NuGet\NuGet.Config
      C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

  Feeds used:
      https://api.nuget.org/v3/index.json
      https://dotnet.myget.org/F/aspnetcore-dev/api/v3/index.json
      https://dotnet.myget.org/F/dotnet-core/api/v3/index.json
      C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
PS Microsoft.PowerShell.Core\FileSystem::C:\Users\mlorbe\sln\app>

[livarcocc]

@mlorbetske Do we know which part of VS locked this assembly? Should we move this bug to NuGet?

[mlorbetske]

@livarcocc unfortunately no, I'm not sure why the assembly was locked. Without more to go on, I'm not certain if it's actionable for NuGet, but they may have seen something like this before & have some ideas.

[chrisahardie]

I'm running into the same issue with 1.0.3. I also have version 2.0 installed as well, FWIW.

[natemcmaster]

I'm seeing this issue, too, on Windows, even with VS closed. The exit code is different on macOS, but after installing 2.0.0 CLI, the first-time NuGet cache warmup fails when using the 1.0.x CLI via global.json.

[livarcocc]

We have turned the fallback folder off temporarily in the 2.0 CLI. Meanwhile, let's use dotnet/cli#6647 to make sure that when we turn it back on, 1.0 cache priming will still work.

[ericwj]

In which repo is that issue? I get a 404 for this one.

[astegmaier]

I see the same Failed to create prime the NuGet cache error when using 1.0.4 CLI (using globals.json) after installing 2.0.0-preview1-005977. @livarcocc - was "turning off the fallback folder" supposed to fix the issue for for folks in my situation? If yes, it doesn't seem to be working for me. If no, is there something else I can do to work around the problem?

[livarcocc]

@astegmaier you are hitting https://github.com/dotnet/cli/issues/6550#issuecomment-302593348. In that case, you need to remove 2.0, run the first run for 1.0 and then add 2.0 back. I have a PR out though that will fix this.

[johnLwith]

Thanks, uninstall 2.0.0-preview1-005977 can works.

[thecodejunkie]

@livarcocc a bit of a necro-bump, but what is the proper solution for this now? I have 2.0.2 and 1.0.3 installed and it fails for me on 1.0.3

[livarcocc]

For 1.0.3, I would suggest uninstalling 2.0.2, running the first experience on 1.0.3 and then putting 2.0.2 back. And I am sorry for the trouble.

Or you could get 1.1.4, where this was fixed and remove 1.0.3.

Or, if you don't care about first run, just turn it off with DOTNET_SKIP_FIRST_TIME_EXPERIENCE=false.

[jstallm]

was getting same issue and was able to work around by executing
dotnet nuget locals all --clear