Home: [CPVM] Error on floating transitive dependencies defined in Directory.Packages.props

[cristinamanum]

Details about Problem

Discuss the behavior for transitive dependencies when defined with floating versions.

• Allowed/Not allowed
• If they are not allowed what is the desired behavior

[cristinamanum]

One scenario to describe the concerns:
Central File : A 1.0.0
B *
Package Dependencies:
A 1.0.0 depends on B strict [1.0.0]
Feed has: A 1.0.0
B 1.0.0
B 2.0.0
Project P depends on A 1.0.0
Restore will result in NU1608 .

Not CPVM enabled projects direct dependencies will lead into the same behavior, however it is less likely that this scenario could happen. The reduced likelihood is because the fact that the direct dependency to the project B should not be needed and is probably a user mistake in the PackageRefrence projects.

Central File : None (CPVM not enabled)
Package Dependencies:
A 1.0.0 depends on B strict [1.0.0]
Feed has: A 1.0.0
B 1.0.0
B 2.0.0
Project P depends on
A 1.0.0 and
B *
Restore will result in NU1608 .

Proposal:
Error on floating versions in the Directory.Packages.props

[anangaur]

I don’t think there should be an error for defining floating versions for packages in the central file - direct or transitive. Whether the package becomes direct or transitive depends on a lot of factors after defining the floating version in the central file. Not sure if I am missing anything but would love to understand more.

[kzu]

This is currently the behavior on .NET5 RC2 and it's quite puzzling.

error NU1011: Centrally defined floating package versions are not allowed.

Why would this be an error? I'd love to learn more about the reasoning behind this design.

Thanks!

[cristinamanum]

Hello @kzu, there were two reasons for which we choose to implement this behavior:

1. The version defined at the central versions will be used for direct resolution and transitive resolution. The floating version resolution is the highest on the server in the rest of the cases is the min version in the specified range. A floating version for direct package dependency in a project P1, may lead to warnings in restore of a different project that happen to pull the floating version as transitive. Through this decision we tried to minimize unexpected cases like these.
2. The central package version file is the place to define specific intent of the package versions. As floating version definition depends on the availability on the feed of the package versions we thought that enforcing a more precise definition is more in-line with the mental model of the central package version file .

We are open for feedback, please add :+1: or :thumbsdown: to this issue; it will help us to reconsider this decision.

[rconard]

@kzu & @batzen,

Just to make sure that we are using the same terminology -

Floating Versions:

<PackageReference Include="ExamplePackage" Version="6.*" />

Version Ranges:

<PackageReference Include="ExamplePackage" Version="[6,7)" />

Are you referring to both "Floating Versions" and "Version Ranges" or just to "Floating Versions" with the * notation?

[batzen]

I was referring to floating versions and haven't tested version ranges as i rarely use them.
I get that it might cause issues as described above and it would totally fine if this was a warning. But making it an error totally prevents floating versions.
I, for example, use floating versions to get the highest minor, patch or pre-release version automatically and don't know of other ways to achieve that.
Especially local development of dependencies would get harder, and it's already harder than it should be (aside from CPVM).

[kzu]

I too use floating versions for local development so I can constantly dogfood locally the packages produced by my main branch, and in CI I switch to fixed versions.

There aren't any real workarounds for this, since even if I produce a fixed version (say MyPackage-main.tip), the nuget cache would assume it never changes and would never actually get a new version.

Since most folks already use WarningsAsErrors for CI/Release builds, I think it's enough if this was a warning, since it would be visible enough and if it pointed to an explanation like the one you gave above, would make it actionable (add a direct reference) and clearly understood.

[batzen]

@rconard Any news on this?
I just had to discover that newer versions of Visual Studio fail silently when using floating versions with CPVM.
That's the worst that can happen to a dev.
VS just does not restore a single project with no hint on what's wrong.

Even worse, but that might be a purely VS related issue, VS ignores my global.json which says SDK = 3.1.300 (where CPVM worked with floating versions) and uses a totally different MSBuild/SDK version instead.