Nuget restore doesn't restore all packages from project.assets.json

[uandrei]

Hi,

I've got a question around why some transitive packages are not downloaded in the local nuget cache, even though they're referenced in the project.assets.json file.

To reproduce this:

1. dotnet new console
2. dotnet add package Microsoft.Azure.EventHubs -v 4.3.2
3. nuget locals all -clear
4. nuget restore .\Temp.csproj

Looking at the project.assets.json file created I see a reference to "System.Diagnostics.Process/4.3.0" in the libraries section of the JSON file, which to my understanding (and correct me if I'm wrong), it's where the "resolved" packages are listed. When I search in my local nuget cache folder (c:\Users<user>.nuget) I don't find any folder for System.Diagnostics.Process.

Any hint on why this happens, would be useful.

Cheers

[zivkan]

NuGet has a feature called fallback folders. If the package exists in the fallback folder, then NuGet doesn't need to download it.

When you look at the assets file, there's a section named "packageFolders". Does it contain more than one directory? Does the package already exist in a directory that is not your global packages folder?

Our nuget.config reference docs defines the fallback package folders section, and if you add it to your nuget.config file with <clear/>, you can prevent any solutions under that directory from using the fallback folders.

[uandrei]

Thanks for this, and yes, there is a fallback folder defined in the project.assets.json file. I've tried removing the package from the fallback folder and indeed Nuget restored it.

However, by adding a simple NuGet.config like this doesn't seem to work:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <fallbackPackageFolders>
        <clear/>
    </fallbackPackageFolders>
</configuration>

Any ideas that could help?

[zivkan]

Did you put the nuget.config file in a project directory, but then restore the solution? That's not supported: https://learn.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior

[uandrei]

The nuget.config, csproj and sln files are all in the same folder. I've tried running the restore using both nuget and the dotnet cli, but the behaviour is the same.

Can I also ask, how do packages make their way in the fallback folder?

[uandrei]

@zivkan any idea why the clear doesn't work?

[zivkan]

No, unfortunately I don't. You could check for typos. Unfortunately NuGet was written to ignore unexpected XML in nuget.config files, presumably for both backwards and forwards compatibility reasons. You also appear to be on Windows, so my next guess would be to check the casing of the nuget.config file, since Linux is case-sensitive and there are only 3 cases that NuGet checks. But Windows is not case sensitive, so that's also an unlikely cause.

You can look at your assets file, and verify if packageFolders contains one, or more than one, location. It lists the global packages folder, and fallback folders. If it only lists one, then that suggests the clear on fallback folders works, in which case I would expect that the package is restored after a successful restore.

Also, I strongly, very strongly, suggest don't use nuget.exe for restore. If you build with dotnet build, then use dotnet restore. If you build with msbuild, then use msbuild -t:restore. If you have any projects using packages.config, use msbuild -t:restore -p:RestorePackagesConfig=true. I don't think it's a cause here, but sometimes if you use a version of nuget.exe that does not match the version of NuGet built into msbuild or the .NET SDK, there can be problems. Ever since NuGet added -p:RestorePackagesConfig=true, there's no longer any good reason to use nuget.exe restore. NuGet.exe restore only has potential for problems that don't exist via msbuild, there are no benefits. But I can't imagine why an old version of nuget.exe would list a package in the assets file that hasn't been extracted to the global packages folder, or already be available in a fallback folder.

Otherwise, if you zip up a sample and share that, I can try restoring locally to see if I encounter the same issue. However, it's dependent on machine state, so I might not encounter the same outcome that you're seeing.