Home: Wrong package dependency version If package dependency version is set to '*'

[livarcocc]

_From @atanasa on March 19, 2018 15:28_

If package dependency version is set to '*', the version in the package spec is set to the version of the package instead of the dependency

Steps to reproduce:

1. Build the following project:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    <Version>1.2.3</Version>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="EntityFramework" Version="*" />
  </ItemGroup>

</Project>

Where "EntityFramework" can be any other package (probably that is not part of the standard library).

1. run dotnet build

Expected output:
A package of version 1.2.3 with a dependency to the package EntityFramework with it latest version (e.g. 6.2.0).

Actual output:
A package of version 1.2.3 with a dependency to the package EntityFramework with version 1.2.3:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>ClassLibrary1</id>
    <version>1.2.3</version>
    <authors>ClassLibrary1</authors>
    <owners>ClassLibrary1</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Package Description</description>
    <dependencies>
      <group targetFramework=".NETStandard2.0">
        <dependency id="EntityFramework" version="1.2.3" exclude="Build,Analyzers" />
      </group>
    </dependencies>
  </metadata>
  <files>
    <file src="...\ReproPackDepVersion\ClassLibrary1\bin\Debug\netstandard2.0\ClassLibrary1.dll" target="lib\netstandard2.0\ClassLibrary1.dll" />
  </files>
</package>

dotnet -info:

.NET Command Line Tools (2.1.101)

Product Information:
 Version:            2.1.101
 Commit SHA-1 hash:  6c22303bf0

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.101\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.6
  Build    : 74b1c703813c8910df5b96f304b0f2b78cdf194d

_Copied from original issue: dotnet/sdk#2062_

[livarcocc]

_From @atanasa on March 19, 2018 15:33_

This used to work in an earlier version of the SDK.

[livarcocc]

Moving this to NuGet for them to have a first look there. NuGet folks, if this is the SDK setting something wrong, just re-activate the original issue.

[Squidcod]

Hey, encountering this as well, any word yet?

[nkolev92]

The problem here is that when * is the version, during restore, the version range in the assets file is written as "(, )" which basically no version, rather than floating.

Then here, when such version is detected, it is default to the version of the current project.
https://github.com/NuGet/NuGet.Client/blob/b404acf6eb88c2b6086a9cbb5106104534de2428/src/NuGet.Core/NuGet.Commands/CommandRunners/PackCommandRunner.cs#L608-L611

The root cause of this is that the ToNormalizedVersion formatting is not round-trippable, although I'm not confident the default in the code I pointed to is correct.

[atanasa]

Any update on this?

[tebeco]

Hello there,

Would definitely love that feature too
In addition with the lockfiles that would be amazing and easier to update / consolidate and be repeatable on repositories ^^

[TFTomSun]

Here's a workaround : https://github.com/NuGet/Home/issues/7328#issuecomment-425942851

[nkolev92]

Suggested workaround is:

[*, ).

The change is scheduled for 5.5.

[tebeco]

YEAAAAHHHHHHHHHHHHHHHHHH

[bpaczkowski]

@nkolev92 May I ask when 5.5 is scheduled to be released? The workaround above does not work for us, using [1.*,2) still translates the first part to the current version, therefore when restoring it will use that version instead of the newest one. We have to edit the resulting nuspec and change the dependency versions manually to 1.* before pushing.

[nkolev92]

As of right now 5.5 is scheduled for Feb/March 2020.

The workaround above does not work for us, using [1.,2) still translates the first part to the current version, therefore when restoring it will use that version instead of the newest one. We have to edit the resulting nuspec and change the dependency versions manually to 1. before pushing.

Not sure what you are suggesting here.
Floating versions are not allowed in the nuspec.
When packing, pack puts the version selected during restore as the min.

This issue only refers to the * case.

[bpaczkowski]

They seem to work for me though. [1.1.0, 2) in the nuspec installs 1.1.0 even if a newer version is available, 1.* in the nuspec restores the latest version, eg. 1.2.0.

[bpaczkowski]

@nkolev92 Could I get an update? Nuget translates 1.* from the csproj to the newest available version at the time in nuspec. But when I manually change it back to 1.* in the nuspec, then when restoring, it will restore the newest version.

I do not understand why in most issues on this repository people mention floating versions aren't supported by nuget, yet according to my tests they are, only I have to manually update nuspec before pushing it out.

Could I get some clarification on this?

[tebeco]

@bpaczkowski

as said by @nkolev92

This issue only refers to the * case.

you seems to speak about 1.* not *
that's probably the confusion

just try this :

• close visual studio
• create a new project like this :

> dotnet new console -n Foo
> cd Foo
> dotnet add package Newtonsoft.Json
> code Foo.csproj

• edit the version to this :
  <PackageReference Include="Newtonsoft.Json" Version="*" />
• run dotnet restore --force --no-cache
• read the warning => "No lower bound ...." it try to fetch 0.0.0 then goes for the lowest possible version

open in visual studio and check the package graph

[nkolev92]

But when I manually change it back to 1.* in the nuspec, then when restoring, it will restore the newest version.

@bpaczkowski There's a bug in there and it will be fixed.

//cc @zivkan Can you link to the issue with the floating version bug?

[tebeco]

@nkolev92

in a scenario where i use [*, 9999.0] and i also use lockfile

is there a way to force transitive to also be restored as highest ?

[nkolev92]

Nope, tracking issue for that https://github.com/NuGet/Home/issues/5553

[tebeco]

thx for the link ;)