dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.7k stars 1.06k forks source link

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

Open chillitom opened 6 years ago

chillitom commented 6 years ago

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:

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 commented 6 years ago

@nguerrera can you take a look?

velvetdust commented 6 years ago

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

chibanemourad commented 6 years ago

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 commented 6 years ago

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

nguerrera commented 6 years ago

@chibanemourad are you also seeing this with the build tools sku in CI or do you have a local repro?

Get Outlook for iOShttps://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 GitHubhttps://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 threadhttps://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 commented 6 years ago

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

chlowell commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

ManuelGalindo commented 6 years ago

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

dzmitrykarnitski commented 6 years ago

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

nguerrera commented 6 years ago

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 commented 6 years ago

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

nguerrera commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

kierenj commented 6 years ago

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 commented 6 years ago

same here: https://github.com/OmniSharp/omnisharp-roslyn/issues/1180

nguerrera commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago
  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 commented 6 years ago
  1. only CI builds
  2. no
  3. VSTS, two steps running msbuild (clean;restore then build)
nguerrera commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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

nguerrera commented 6 years ago

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 commented 6 years ago

2233 tracks the longer term work on clean

michael-freidgeim-webjet commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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