Need consistent way of getting NuGet package cache location from MSBuild

[clairernovotny]

Currently NUGET_PACKAGES can be used to alter the package cache location. The issue is that anything in custom msbuild targets that need to call into packages have to check multiple possible locations since there is no consistent property defined for this purpose.

The default is %USERPROFILE%\.nuget\packages, and as NUGET_PACKAGES isn't widely used, to workaround other issues, or simply to access tools within a package, many build scripts "hardcode" a path like this:
https://github.com/NuGetPackageExplorer/NuGetPackageExplorer/blob/22e4d8b20bf5efb40ea10620aef6c55f69dbbf3c/Directory.Build.props#L33-L36
or https://github.com/NuGetPackageExplorer/NuGetPackageExplorer/blob/22e4d8b20bf5efb40ea10620aef6c55f69dbbf3c/.vsts.nightly.ci.yml#L22

In those cases, if NUGET_PACKAGES is set, it'll cause builds to be incorrect or break.

I propose that a new property be added to the build-in/default NuGet props that calculates this correctly and is defined for this purpose. Default to %USERPROFILE%\.nuget\packages but return %NUGET_PACKAGES% if set.

/cc @chrispatterson @AArnott

[AArnott]

What's wrong with projects using the $(NugetPackageRoot) property, defined in the nuget-generated *.csproj.nuget.g.props file?

    <NuGetPackageRoot Condition=" '$(NuGetPackageRoot)' == '' ">$(UserProfile)\.nuget\packages\</NuGetPackageRoot>

[clairernovotny]

I don't recall the context, maybe it was from @davkean, but I don't think that's documented and it could be removed or redefined.

[clairernovotny]

One other thing, that variable isn't available to scripts. The VS DevCmd script that sets up the environment vars should set something as well.

[emgarten]

The property @AArnott mentioned sounds like what you are asking for. This property isn't used internally, it is there for writing custom targets or for use from a package. It is unlikely this would change.

One other thing, that variable isn't available to scripts. The VS DevCmd script that sets up the environment vars should set something as well.

The default package folder path is user specific, but beyond that this path can be set on a per-project basis, which means there is no right answer apart from where the project lists as the packages folder. dotnet.exe restore --packages c:\tmp will put them there instead of in the default location. It is also possible to define RestorePackagesPath in the project to override the location. And with fallback folders the packages could be spread out and not in the default user location (.g.props lists these also).

What has been proposed for build scripts your example is to have an MSBuild task that can ensure a package exists, downloading it if needed, and put it in the default packages folder. Then return the path to it. Or search known package locations and find it, and give you the path. #5919

[clairernovotny]

@emgarten if that property is going to be stable, I'm happy to use it and the script issue can be dealt with separately.

[emgarten]

It is stable 🍰

[vpenades]

Sorry for commenting on a closed issue: $(NugetPackageRoot) is not as consistent as it might seem...

We've found that in most cases, it points to C:\Users\*user*\.nuget\packages\ but in a few others it points to C:\Temp\.nuget\packages Notice the missing slash in the second case. This detail is causing us some headaches.

[AArnott]

You can use the msbuild function EnsureTrailingSlash to help you.

[Joev-]

Apologies also for the necro on this issue, but I am also suddenly facing inconsistencies with $(NugetPackageRoot).

Our build agent is generating a value that is missing the trailing slash, running VS2017 15.9.5. I am not against using an MSBuild function if it turns out to be really necessary, but I would like to understand why this is happening suddenly. Any clues are much appreciated as the agent is fairly vanilla and I'm at a loss of what could have changed.

Edit: I've narrowed this down to our build agent being switched to running under the system account rather than a user account. Why would the system account cause the trailing slash to not appear for this specific property?