Nuget 3.5 restore under LocalSystem account

[sm-g]

Details about Problem

NuGet version (3.5.0.1938) OS win server 2012

Detailed repro steps so we can see the same problem

project.json is

{
  "version": "1.0.0-*",
  "dependencies": {
    "Moq": "4.5.10",
    "Moq.Sequences": "1.0.1",
    "Newtonsoft.Json": "9.0.1",
    "NUnit": "3.5.0",
    "NUnitLite": "3.5.0"
  },
  "frameworks": {
    "net461": {}
  },
  "runtimes": {
    "win": {}
  }
}

project.lock.json contains

      "Moq/4.5.10": {
        "type": "package",
        "dependencies": {
          "Castle.Core": "3.3.3"
        },
        "compile": {
          "lib/net45/Moq.dll": {}
        },
        "runtime": {
          "lib/net45/Moq.dll": {}
        }
      },
      "Moq.Sequences/1.0.1": {
        "type": "package",
        "dependencies": {
          "Moq": "4.0.0",
          "NUnit": "2.5.0"
        },
        "compile": {
          "lib/net40/Moq.Sequences.dll": {}
        },
        "runtime": {
          "lib/net40/Moq.Sequences.dll": {}
        }
      },

But C:\Windows\System32\config\systemprofile.nuget\packages has no folders.

Verbose Logs

NuGet Version: 3.5.0.1938 Running restore with 2 concurrent jobs. Reading project file C:\TeamCity\buildAgent\work\92c1a2b89cb52a9a\src\X\project.json. Restoring packages for C:\TeamCity\buildAgent\work\92c1a2b89cb52a9a\src\X\project.json... Restoring packages for .NETFramework,Version=v4.6.1... Resolving conflicts for .NETFramework,Version=v4.6.1... Scanning packages for runtime.json files... Restoring packages for .NETFramework,Version=v4.6.1 (win)... Resolving conflicts for .NETFramework,Version=v4.6.1 (win)... Checking compatibility of packages on .NETFramework,Version=v4.6.1. Checking compatibility for X 1.0.0 with .NETFramework,Version=v4.6.1. Checking compatibility for Moq 4.5.10 with .NETFramework,Version=v4.6.1. Checking compatibility for Moq.Sequences 1.0.1.0 with .NETFramework,Version=v4.6.1. Checking compatibility for Newtonsoft.Json 9.0.1 with .NETFramework,Version=v4.6.1. Checking compatibility for NUnit 3.5.0 with .NETFramework,Version=v4.6.1. Checking compatibility for NUnitLite 3.5.0 with .NETFramework,Version=v4.6.1. Checking compatibility for Castle.Core 3.3.3 with .NETFramework,Version=v4.6.1. All packages and projects are compatible with .NETFramework,Version=v4.6.1. Checking compatibility of packages on .NETFramework,Version=v4.6.1 (win). Checking compatibility for X 1.0.0 with .NETFramework,Version=v4.6.1 (win). Checking compatibility for Moq 4.5.10 with .NETFramework,Version=v4.6.1 (win). Checking compatibility for Moq.Sequences 1.0.1.0 with .NETFramework,Version=v4.6.1 (win). Checking compatibility for Newtonsoft.Json 9.0.1 with .NETFramework,Version=v4.6.1 (win). Checking compatibility for NUnit 3.5.0 with .NETFramework,Version=v4.6.1 (win). Checking compatibility for NUnitLite 3.5.0 with .NETFramework,Version=v4.6.1 (win). Checking compatibility for Castle.Core 3.3.3 with .NETFramework,Version=v4.6.1 (win). All packages and projects are compatible with .NETFramework,Version=v4.6.1 (win). Committing restore... Lock file has not changed. Skipping lock file write. Path: C:\TeamCity\buildAgent\work\92c1a2b89cb52a9a\src\X\project.lock.json C:\TeamCity\buildAgent\work\92c1a2b89cb52a9a\src\X\project.json Restore completed in 442ms.

NuGet Config files used: C:\Windows\system32\config\systemprofile\AppData\Roaming\NuGet\NuGet.Config C:\ProgramData\nuget\Config\Microsoft.VisualStudio.Offline.config

Feeds used: https://api.nuget.org/v3/index.json C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

[emgarten]

Set the environment variable NUGET_PACKAGES to a different folder location to override the path.

[danroth27]

A customer today reported a similar issue where they were able to successfully restore from a local system account, but the packages could not be resolved at build time because of confusion between the system32 path and the sysWOW64 path.

[emgarten]

@danroth27 do you think a warning in the nuget output would have helped?

[sm-g]

Another stranges:

C:\Windows\system32>nuget locals all -clear
Clearing NuGet HTTP cache: C:\Windows\system32\config\systemprofile\AppData\Loca
l\NuGet\v3-cache
Clearing NuGet cache: C:\Windows\system32\config\systemprofile\AppData\Local\NuG
et\Cache
Clearing NuGet global packages cache: C:\Windows\system32\config\systemprofile\.
nuget\packages\
Local resources cleared.

After that C:\Windows\system32\config\systemprofile\.nuget\packages\ still contains all folders with content.

[danroth27]

To help diagnose the issue I think it would have helped to be able to see very clearly in the output:

• Where on disk restored packages were installed
• Where exactly the build process looked for packages

I also agree with @sm-g that the output of nuget locals all -clear was very misleading. It says it successfully cleared the caches, but the files were still there! I'm guessing this was due to some oddities around how local system account profiles work?

[tofutim]

Hi, I have a related problem with my netstandard library and nuget. When I run 'nuget restore my.sln' with SYSTEM (via TeamCity or command line), I end up with the packages in the packages directory on the solution root. However, as it is processing, it creates a project.lock.json file which at the very end points to "C:\Windows\system32\config\systemprofile.nuget\packages" and so the project always fails to build.

"projectFileToolGroups": {}, "packageFolders": { "C:\Windows\system32\config\systemprofile\.nuget\packages\": {} }

This is probably a nuget issue bit it is an odd one. If I run from any other account, it works fine and either the packageFolders is blank or it points to somewhere where nuget restores to.

The strange thing is that I think this used to work.

[tofutim]

## The 'nuget restore' places the files in SysWow64 but writes " "C:\Windows\system32\config\systemprofile\.nuget\packages\": {}" into the project.lock.json file.

So, I think the issue is probably that 'nuget' being a 32-bit app, writes the SYSTEM packages to SysWOW64.

And setting NUGET_PACKAGES does not seem to change where anything

Update. In NuGetEnvironment.cs,

case NuGetFolderPath.NuGetHome:
                    return Path.Combine(
                        GetFolderPath(SpecialFolder.UserProfile),
                        ".nuget");

Update2. Scratch that, I think NUGET_PACKAGES just worked. In case anyone needs it

I do think it is a bug that under SYSTEM, the packages get written to SysWow64 but the project.lock.json says system32.

Extra. Incidentally, I think it "worked before" because that was when dotnet restore was working for me. Now that dotnet restore no longer works (something about portable not being found in preview4), I'm back to using nuget 3.5.

[dtretyakov]

@emgarten, lots of TeamCity customers faced with this problem and it's quite critical since it significatly suffers UX of using so trendy .NET Core projects.

Do you have estimates when it will be resolved?

[maartenba]

Also seeing this, kind of annoying.

[emgarten]

Restore could fail with a message saying to set NUGET_PACKAGES if it detects this situation.

This would be a breaking change however for users who currently have this working by using the system folder.

[theCuriousOne]

I came to the same problem and it seems to be miraculously fix when I add <ReferenceOutputAssembly></ReferenceOutputAssembly> inside the .csproj file for which assembly is causing the error.

[medianick]

The nuget.exe (4.9.3) output was misleading when running the restore under a Local System account (as we do on our Jenkins servers); it claimed to be using C:\Windows\system32\config\systemprofile\AppData\Roaming\NuGet\NuGet.config as a configuration but in fact was using C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\NuGet\NuGet.config. I was able to fix our problem by opening the first file and copying its contents into the second. This had manifested as an inability to find and restore packages from our private MyGet feed, which indeed was only configured in the system32-based config location.