Method 'System.IO.Directory.GetParent' not found in Microsoft.PackageDependencyResolution.targets

Getting the error discussed below on a CI box that has VS2017 Build Tools installed. The build completes successfully on my workstation where I have VS2017 Professional 15.5 installed.

The solution is being built using MSBuild as the dotnet build command fails due to this issue with ResX files: https://github.com/Microsoft/msbuild/issues/2221

Versions:

• NuGet: 4.5.1
• MSBuild version ‘15.5.180.51428’ from ‘C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin’.
• dotnet sdk: 2.1.4

Building the solution with:

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe E:\Jenkins\workspace\Solution\src\Solution.sln /t:Build /m /nodeReuse:False /tv:15.0 /p:RestorePackages="False" /p:Configuration="Release"

The error:

14>C:\Program Files\dotnet\sdk\2.1.4\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(557,9): error MSB4186: Invalid static method invocation syntax: "[System.IO.Directory]::GetParent().get_Name()". Method 'System.IO.Directory.GetParent' not found. Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(a, b)). [E:\Jenkins\workspace\Solution\src\Project\Project.csproj]

Which appears to come from this line:

553      <!-- These resource items are in folders with names which correspond to the locale.  Here, set the DestinationSubDirectory to the
554           folder name so that it will be copied to the right target path and so conflict resolution won't think there are conflicts
555           between satellite assemblies in different languages. -->
556      <_ResourceCopyLocalItems Update="@(_ResourceCopyLocalItems)" Condition="'@(_ResourceCopyLocalItems)' != ''">
557        <DestinationSubDirectory>$([System.IO.Directory]::GetParent(%(ResolvedPath)).get_Name())\</DestinationSubDirectory>
558      </_ResourceCopyLocalItems>

It appears that for some reason ResolvedPath is blank causing MSBuild to look for a method that doesn’t exist.

Closest I’ve found from googling is this blog post. Unfortunately his solution was to switch to MSBuild which we’re already using.

[rainersigwald]

@nguerrera One problem we’ve seen with builds running as system is running programs with different bitnesses. Since C:\Windows\system32\config\systemprofile is under system32, it’s subject to WoW redirection, and a 64-bit program won’t see the same files in that directory as a 32-bit program. Not 100% sure that’s relevant here but throwing it out.

[pioksi]

I just found an instance of this error in the following situation with an internal user, where:

1. Builds were running as the SYSTEM user.
2. Packages were getting restored to "C:\Windows\system32\config\systemprofile.nuget\packages"
3. During build, NuGet API returns null for path to assets that were restored there causing ResolvedPath=(empty)
4. Empty ResolvedPath leads to this expression becoming invalid and the error reported here

Other things would break in this situation, but this error is what is hit first. I don’t know why (3) happens yet. I suspected MAX_PATH, but it is not especially long.

If this sounds like it might match your situation, you can configure the restore directory in one of two ways:

1. Add a NuGet.config at the root of your repo and set globalPackagesFolder to a relative path from there

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="globalPackagesFolder" value="packages" />
  </config>
</configuration>

1. Configure the build to have NUGET_PACKAGES environment variable set to a full path to where you want packages to be restored

Hello, thx for those points, they were very useful. I had MSB4186 on build server but after instaling VS 15.8 it changed to error NETSDK1064: Package <some package name and version> was not found. Even that it was present in “C:\Windows\System32\config\systemprofile.nuget\packages” folder. So adding NuGet.config file with globalPackagesFolder set to my project packages folder resolved the issue. I’m very interested in the final solution though, because this one I consider as a workaround.