Floating version problem

[dominikjeske]

I'm using nugetizer 0.6 and have following issue when using floating versions. In my project I have PackageReference like this

<PackageReference Include="packageName" Version="1.0.1-preview.*" />

on my artifactory I have this package in versions from preview.1 to preview.6 but package created from my project have dependency with version 1.0.1-preview.0

When nugetizer is removed from project package dependency have proper 1.0.1-preview.6 version which point to actual version. It looks like nugetizer is not handling floating versions properly?

[michalrosenbaum]

Just to visualize/help with reproducing, let's say that we have these packages in the feed: SomeDependencyOfNestedPack.1.0.1.nupkg SomeDependencyOfNestedPack.1.0.2.nupkg

If a nested project packed with the root package has the following reference with a floating version such as: <PackageReference Include="SomeDependencyOfNestedPack" Version="1.0.*" />

The resulting version in the nuspec of the root package is going to be: <dependency id="SomeDependencyOfNestedPack" version="1.0.0" />

The floating part always evaluates to "0". It creates a problem since such a version doesn't even exist in the feed, so later during restore the version 1.0.1 will be taken because it's the nearest to 1.0.0, but it's not the latest.

This is how we reference NuGetizer:

<PackageReference Include="NuGetizer" Version="0.6.0">
    <PrivateAssets>all</PrivateAssets>
    <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>

[kzu]

You can't reference floating versions when packing. This is not supported in nuspec neither nuget packaging APIs, AFAIK.

And it makes sense, since you would end up with non-deterministic packages where the exact same checkout/commit can produce different packages.

[maciejw]

@kzu this is interesting problem, but correct me if I'm wrong, restore can use floating version and pack is using version that was restored at the time, that is in package.assets.json? with lockfile (its an assets json that is commied to repo) you have deterministic restore and in nuspec you should have fixed version.

even with fixed version in packagereferece you have kind of floating behavior, because version in package reference means version equal or greater and when packages is feed change, restore graph can change also, even if you are using same exact commit.

Update: I've checked it on sample project here is package reference

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Lib1" Version="1.0.*" />
  </ItemGroup>
</Project>

here is nuspec after dotnet pack

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>Lib2</id>
    <version>1.0.0</version>
    <authors>Lib2</authors>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Package Description</description>
    <dependencies>
      <group targetFramework=".NETStandard2.0">
        <dependency id="Lib1" version="1.0.2" exclude="Build,Analyzers" />
      </group>
    </dependencies>
  </metadata>
</package>

[kzu]

Fair point. This is very low priority for me personally since I never use checked-in lock files, so I get my determinism from the actual fixed versions in the package reference instead (and let dependabot bump those for me as needed).

I'll gladly take a PR that adds this behavior, though. Perhaps the right sponsorship level would also work :).

Thanks for clarifying the intended scenario and expected behavior :+1: