Custom msbuild sdk results in "Package restore was successful but a package with the ID of "xyz" was not installed"

[jeffkl]

From @japj on February 20, 2019 15:16

Steps to reproduce

I am trying to build a custom msbuild sdk, and have published this successfully to a TFS 2018Update3 PackageManagement feed.

However I run into the issue that upon first time use of a new version of this sdk I get a "Package restore was successful but a package with the ID of "xxx" was not installed" error.

I can confirm that the NuGetSDKResolver has downloaded the nuget correctly and placed it in the global nuget cache with the correct version.

If I run the test project through msbuild a second time it succeeds to import sdk.props/targets from the custom sdk.

I have also tried the same with a simple example and "Microsoft.Build.CentralPackageVersions" and this always goes ok on the first try (so I can not replicate the issue with that NuGet sdk).

I have tried comparing contents of these Sdks (and nuget spec files) to see if I can understand why it is going wrong, but I cannot figure out what the exact cause is.

Any information on how to further analysis & fix this issue?

Project file sample2.proj goes wrong (with custom SDK)

  <Sdk Name="xyz" Version="0.3.32-gb626b61888"/>
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
  </ItemGroup>
</Project>

Project sample.proj goes ok (with Microsoft.Build.CentralPackageVersions)

  <Sdk Name="Microsoft.Build.CentralPackageVersions" Version="2.0.1" />
  
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
  </ItemGroup>
</Project>

The custom SDK has the following relevant MSBuild information in the nuspec:

<tags>MSBuild MSBuildSdk</tags>
<packageTypes>
      <packageType name="MSBuildSdk" />
</packageTypes>

Environment data

msbuild /version output:
Microsoft (R) Build Engine version 15.8.166+gd4e8d81a88 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

15.8.166.59604

OS info:
Windows 10 1703 (15063.1387)

Copied from original issue: dotnet/msbuild#4190

[jeffkl]

After restore, the SDK resolver looks for your SDK based on the restore results:

https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/Microsoft.Build.NuGetSdkResolver/NuGetSdkResolver.cs#L150

Is the version and ID of the package exactly the same? Maybe the case is different? Can you attach a NUPKG of an SDK that doesn't work?

[jeffkl]

From @japj on February 20, 2019 16:32

Yes indeed, casing is the issue here.

I can reproduce the problem by:

• remove C:\Users\japj.nuget\packages\microsoft.build.centralpackageversions
• run msbuild test.proj with the following content in test.proj:

<Project>
  <Sdk Name="Microsoft.Build.CENTRALPACKAGEVERSIONS" Version="2.0.1" />
</Project>

Thanks for the quick pointer, not sure if there is still an issue that needs to be solved though.
I would have expected it to either "always fail" or "always succeed".
Now it fails the first time, but succeeds after it has previously been downloaded and you run it the 2nd time.

[jeffkl]

I think it succeeds the second time because its already downloaded and there's different logic for locating an on disk package versus one that was just fetched.

I think the fix is to just add a StringComparison to that Equals() call so that its not case sensitive. I'm going to move this issue to the NuGet repo since thats where the NuGetSdkResolver lives now.

Thanks for reporting this!

[rrelyea]

Right assignee?
@livarcocc

[livarcocc]

Not really. I have assigned it to myself for now.

[livarcocc]

Or rather, you have to. I can't change assignments here.

[rrelyea]

I cannot assign to you either. Want me to add you to this repo, or port this issue elsewhere?