Floating references and NuGet package generation

[RobSwDev]

I have 3 .Net projects A, B, C that are built and released (via NuGet ) separately. Project A references both B and C, while B references C using floating versions in the PackageReference. Each references version 4.1.*.

Unfortunately, when the NuGet package for B is built, it crystallizes the version of C from 4.1.* to the latest version available: say 4.1.7. This means that when we make a new release of C, we are also forced to make a new release of B, otherwise building A fails with package downgrade errors.

It says in the docs that floating versions are not supported. However, a floating version can easily be converted into a range can't it?
I.e. 4.1.* is equivalent to [4.1.0, 4.2.0)

What I want is for the NuGet package dependencies to be generated using an equivalent version range to the floating version specified in the package reference (rather than crystallized at whatever the latest version is when the NuGet package is built). Is there any way of doing this? If not, would it be a reasonable feature request (e.g. as an optional property on the package reference)?

[zivkan]

https://docs.microsoft.com/en-us/nuget/concepts/package-versioning has more in depth documentation about versions, including ranges and floating versions.

In short, version x is equivalent to [x, ), so technically it is a range, just with no upper bound. This means that 4.1.* is equilvant to [4.1.*, ). If you want to upper bound it to 4.2.0, you should use [4.1.*, 4.2.0).

Next, NuGet is conservative when it comes to package compatibility. in the case of * or 1.*, according to SemVer2 rules, package authors can add new APIs. Therefore, if your project uses 1.*, it's not safe to assume that a dependency of 1.0 is the lower bound. Otherwise, when someone uses your package, they'd get the lowest version of your dependency, and then your assembly will crash with a MethodNotFoundException at runtime. By packing with the dependency version that your project was restored with, this at least
This is the reason that NuGet uses the actually resolved version at restore time as your package dependency minimum bound at pack time. While you could argue that 1.2.* is not allowed to add new APIs according to SemVer2 rules, NuGet doesn't know whether or not the package author actually follows SemVer2. For example, NuGet itself does not, we follow Visual Studio's major and minor version number (minus 11.0), for our NuGet.* packages on nuget.org.

Projects that get packed and referenced by other projects are usually class libraries, not exe's. Therefore, if using 4.2.0 as the minimum bound for your packages is important to you, I suggest using 4.2.0 as your PackageReference version for your classlibs, and in your console/web/wpf/whatever app, the actual executable, in that project use 4.2.*.

Finally, NuGet treats package downgrade (NU1605) as a warning, but [the .NET SDK elevates it to an error]( $(WarningsAsErrors);NU1605). This means your project can remove NU1605 from WarningsAsErrors in your csproj. Alternatively, you can remove C as a direct reference from A, so it gets B's transitive version.

Also, your first paragraph makes it sound like A, B, and C are all in the same repo/solution. Why not make them all ProjectReferences? I don't understand why B would use C as a PackageReference instead of a ProjectReference.

[RobSwDev]

Thanks for your response. Apologies - it seems I misunderstood how nuget works. In particular, that x is equivalent to [x, ).

• We'd prefer not to turn off NU1605, and in any case, these downgrades apparently sometimes causes runtime errors (Could not load file or assembly...) for us.
• Removing references that automatically come in transitively anyway may be an option - I'll certainly look into this next time this issue comes around.
• A is a unit test project. B and C are both (reusable) test utility libraries. They're all in different repos/solutions, so I cannot use project references.

There's 1 bit I don't understand:

Therefore, if your project uses 1.*, it's not safe to assume that a dependency of 1.0 is the lower bound.

Why is this?
Is it purely a syntax thing (there's no PackageReference syntax to specify we want 1.x but at least 1.5)
Or is it required because of some consequence of "nearest wins"?
Or something else?
Naively, I see 1.* as meaning anything above 1.0: that the project should work fine with v1.0 of the dependency package.

Given identical source and build tools, the nuget package built from that source varies depending on what dependency packages exist in the nuget feed at the time of building. This doesn't seem ideal to me.

[zivkan]

Say I have a package zivkan.Things, and in v1.0.0 I have only one public API: static void zivkan.DoFirstThing();. Then in v1.0.1 of the package, I add static bool zivkan.CanDoFirstThing();.

Now I create another another library, zivkan.Stuff that uses <PackageReference Include="zivkan.Things" Version="1.*" />. When I restore zivkan.Stuff, I get zivkan.Things version 1.0.1. Not knowing that zivkan.CanDoFirstThing() only exists in package version 1.0.1, and not in 1.0.0, I use it in zivkan.Stuff.

Finally, someone uses zivkan.Stuff in their console app.

• If zivkan.Stuff lists zivkan.Things version 1.0.1 as a dependency, then the console app will get version 1.0.1 of zivkan.Things, and the console app works.
• if zivkan.Stuff lists zivkan.Things version 1.0.0 as a dependency, then the console app will get version 1.0.0 of zivkan.Things. The console app will call zivkan.Stuff's API, and the implementation will try to call zivkan.CanDoFirstTHing() from zivkan.Things.dll. However, since version 1.0..0 was restored, the console app will crash with a MethodNotFoundException.

[RobSwDev]

Ok, thanks Zivkan. Makes sense.