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

[chillitom]

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: dotnet/msbuild#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.

[livarcocc]

@nguerrera can you take a look?

[velvetdust]

I have the same problem actually. Microsoft.PackageDependencyResolution.targets(557,9): error MSB4186 too

[chibanemourad]

I have the same error :
C:\Program Files\dotnet\sdk\2.1.101\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)).

[nguerrera]

I haven't gotten to the bottom of this but it is worth noting that this code no longer exists in master.

[nguerrera]

@chibanemourad are you also seeing this with the build tools sku in CI or do you have a local repro? Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Nick Guerrera <notifications@github.com> Sent: Monday, March 19, 2018 10:12:16 AM To: dotnet/sdk Cc: Nick Guerrera; Your activity Subject: Re: [dotnet/sdk] Method 'System.IO.Directory.GetParent' not found in Microsoft.PackageDependencyResolution.targets (#1967) I haven't gotten to the bottom of this but it is worth noting that this code no longer exists in master. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fsdk%2Fissues%2F1967%23issuecomment-374291712&data=04%7C01%7CNick.Guerrera%40microsoft.com%7C9da6bd674b9943b69c4008d58dbc91ce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636570763426449656%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=QXEs0RWxv64Fb0vPpadAUZfBycb1pA1ZX1vveh1aJmQ%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAEmzjHHZA80W8FdP8jP4zESbLDHun4vks5tf-bwgaJpZM4SIqQt&data=04%7C01%7CNick.Guerrera%40microsoft.com%7C9da6bd674b9943b69c4008d58dbc91ce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636570763426449656%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=uXGqai9NjPvQxZ%2BxkmfQqMtg5fgWFvEblWdIZZCCj8w%3D&reserved=0>.

[Bconteh]

I'm having the same error. Anyone got solution for this error?

[chlowell]

@nguerrera I'm seeing this intermittently in a VSEng 2017 pool, it's intermittent even on particular hosts. I can't reproduce it locally. You mention the code no longer exists in master--has a version shipped without it?

[nguerrera]

No version has shipped without it except for unofficial daily builds. There will be a 2.1.300-preview2 shortly that will not have it.

[chibanemourad]

@nguerrera I seeing this with the build tools sku in CI

[ManuelGalindo]

@nguerrera Im presenting the issue, Is there a way to make a workaround like overwrite the file Microsoft.PackageDependencyResolution.targets?

[dzmitrykarnitski]

Same issue on CI environment. Does anyone have a solution for that?

[nguerrera]

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>

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

[nguerrera]

I am trying to set up a repro on a VM so that I can debug exactly why the resolution fails.

[nguerrera]

Adding this to 2.1.3xx because I now see that even if we got past this error (for code that doesn't exist in 2.1.3xx) we would still fail to build if we can't resolve the asset path.

[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.

[jceddy]

We're having the same error...adding NuGet.config to the sln root did not make a difference.

[kierenj]

I'm getting this via OmniSharp in VS Code, the C# plugin:

[fail]: OmniSharp.MSBuild.ProjectLoader
        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`)).

[andycmaj]

same here: OmniSharp/omnisharp-roslyn#1180

[nguerrera]

@kierenj @andycmaj I've commented on OmniSharp/omnisharp-roslyn#1180

@jceddy, and any other folks seeing this error, please provide all of the following details.

1. Can you reproduce the problem locally or only in CI builds?
2. Are your CI builds running as the SYSTEM user?
3. What commands/tool do your builds use to restore and build:
   Examples:
   • One-step using dotnet: dotnet build
   • One-step using msbuild: msbuild /restore
   • Two-steps using a mix of tools: nuget.exe restore && msbuild or dotnet restore && msbuild

[nguerrera]

One problem we've seen with builds running as system is running programs with different bitnesses.

@rainersigwald Indeed I can reproduce the problem by restoring with a 64-bit executable (dotnet restore) and building with a 32-bit executable (msbuild). Thanks for the hint!

[ManuelGalindo]

1. CI Builds using VSTS
2. Yes
3. VSTS Tasks to build asp.net applications
   Two-steps using a mix of tools: nuget.exe restore && msbuild

[chlowell]

1. only CI builds
2. no
3. VSTS, two steps running msbuild (clean;restore then build)

[nguerrera]

@ManuelGalindo Thanks. This matches the issue that I've been able to reproduce so far.

@chlowell Thanks. This does not match any repro I've seen yet. Can you provide the full command lines for your restore step and your build?

[nguerrera]

@chlowell I see earlier that your issue is intermittent. Is it possible that your CI build machines are shared and something is clearing the nuget cache between restore and build?

[chlowell]

Looks like the problem in my case was caused by running the msbuild clean target. Foregoing that seems to have solved it.

[nguerrera]

To add more detail (@chlowell and I talked offline). Clean will currently fail (with this error in RTM Sdks, and a better one in recent 2.1.300 pre-release bits) if packages in project.assets.json have been removed from the nuget cache since prior restore.

I presume the cache was getting emptied between builds sometimes. I suggested using the option in VSTS to clean the repository at the git level over running /t:Clean at the start of each build. The latter is generally much safer for CI. The problem with /t:Clean is that its correctness is always a function of the correctness of the prior build and you shouldn't assume that applies to a CI environment. You don't want a bug in a previous job to impact subsequent jobs.

That said, it's basically a bug that we're reading the assets during Clean and I'm working on addressing it. #2229 is a small step, but there's going to be more needed.

[nguerrera]

#2233 tracks the longer term work on clean

[michael-freidgeim-webjet]

I had the same error in 3 MSTest projects that refer to the test helpers project. The helpers csproj file was corrupted (had unresolved git markers like '<<<head'), but error messages were confusing.The MSTest projects have the same :

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)). IntegrationTests C:\Program Files\dotnet\sdk\2.1.4\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets 557

[nguerrera]

@michael-freidgeim-webjet Do you have a global.json pinning to sdk 2.1.4? Can you try removing that or updating the version to 2.1.400 that came with VS 15.8.

[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.

[nguerrera]

I am going to close this as it it fixed in 2.1.300+ and there's a workaround: set globalPackagesFolder in nuget.config for older versions.

[nguerrera]

Reopening as I remember now that the symptom will have changed in 2.1.300, but packages will still fail to resolve.