Messages about packages not containing a version range after updating from 6.12.2 to 6.13.1

[PaulVrugt]

NuGet Product Used

NuGet.exe

Product Version

6.13.1 .net framework

Worked before?

6.12.2

Impact

I'm unable to use this version

Repro Steps & Context

I don't know what exactly causes this. We are using:

• central package management
• transitive pinning.
• restoring in locked mode

We have a large list of nuget packages used in the repo. Only the restores for .net framework 4.8 projects seem affected.

The error we are getting is:

##[error]The nuget command failed with exit code(1) and error(NU1004: Central package management file(s) doesn't contain version range for <SomePackage> package which is specified as CentralTransitive dependency in the lock file.The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode. Disable the RestoreLockedMode MSBuild property or pass an explicit --force-evaluate option to run restore to update the lock file.
Errors in <my project file>

The error always seems to be about the same nuget package, which is in our private nuget repo. I've checked and the central package management file seems fine:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
    <CentralPackageTransitivePinningEnabled>true</CentralPackageTransitivePinningEnabled>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="The failing package" Version="2.0.0" />
</Project>

the project file referencing the package contains a normal reference:

<PackageReference Include="The failing package" />

the package lock file:

{
  "version": 2,
  "dependencies": {
    ".NETFramework,Version=v4.8": {
      "project referencing the pacakge": {
        "type": "Project",
        "dependencies": {
          "the failing package": "[2.0.0, )"
        }
      },
      "the failing package": {
        "type": "CentralTransitive",
        "requested": "[2.0.0, )",
        "resolved": "2.0.0",
        "contentHash": "the hash",
        "dependencies": {
          "some dependency": "2.0.0"
        }
      }
    }
  }
}

the error seems to occur because with nuget 6.13.1, the package has changes from CentralTransitive to Transitive, while all other (similar) packages, are still set as CentralTransitive:

"the failing package": {
  "type": "Transitive",
  "resolved": "2.0.0",
  "contentHash": "4zO1r6/LPJnvDiUmB1LixJaxc/D305Wue5IwQ3PzwMkCrVSVYAexa0iTPYZcADoi7SuhRf5pCJORkd1WWPaDHw==",
  "dependencies": {
    "Infoland.WebControls3.Base": "2.0.0"
  }
}

I'm in doubt as to if this is a bug, or a bugfix in the new version. But if this is a bugfix, I would have expected more packages that are referenced in the same way to change from CentralTransitive to Transitive.

Verbose Logs

[PaulVrugt]

It turned out to be a casing issue. The nuget package had different casing from how it was defined in the central nuget package management list and the project referencing it. Not sure if it is still a bug, but we are no longer having issues with it

[nkolev92]

@PaulVrugt

The nuget package had different casing from how it was defined in the central nuget package management list and the project referencing it

Just a clarification, the nuspec casing itself was different from the project file and directory.packages.props?
Was the casing between the project file & directory.packages.props different?

I think we still need to investigate here, since the change from CentralTransitive to Transitive.

Are you using floating versions by any chance? I'm assuming no, but I'm just trying to trace potential regressions.

Final question, does fixing the case address the transitive/central transitive issue as well?

[PaulVrugt]

Just a clarification, the nuspec casing itself was different from the project file and directory.packages.props? Was the casing between the project file & directory.packages.props different?

The casing between the project file and directory.packages.props was the same, but it was different from the casing in the nuspec file.

Are you using floating versions by any chance? I'm assuming no, but I'm just trying to trace potential regressions.

We are NOT using floating versions

Final question, does fixing the case address the transitive/central transitive issue as well?

yes, now that i've changed the casing, the transitive/central transitive issue was also fixed. The only change in the lock file was that it changed the casing there as well.

So to summarize what i did to fix it:

• I Change the casing in both the project file and directory.packages.props file
• This resulted in the casing to also be changed in the packages.lock.json
• This also caused the reference to change back from Transitive to CentralTransitive