Build failure on referenced unlisted minimum-version-dependencies

[Thorium]

Description

I used Paket and Fake out-of-box, via project scaffold.
I added a dependency to Owin (v.1.0.0) and Paket generated it to my NuGet package as follows:
Owin (>= 1.0.0-prerelease && <= 1.0.0)

And everything worked fine and everyone was happy. Until one day, the Owin-team unlisted the prerelease-version of the package from NuGet. Now my users started to get build errors.

This is probably a problem of NuGet-protocol in general, but as we know, they are not an open-source project accepting pull-requests. * Meanwhile Paket is the default .NET-solution to tackle NuGet-problems.

I use the following configuration:

paket.template:

dependencies
    Owin 1.0.0 ~> LOCKEDVERSION

paket.lock:

    Owin (1.0)

[matthid]

Unlisting should not break the build, this might be a paket bug.
If they however decided to delete it than failing is the correct thing to do.

[Thorium]

IMHO it shouldn't matter if the existing minimum history package is cleaned (deleted) as long as there still is the maximum correct one available and it's ok to use that. In this case the only Owin package is there still and it's ok. I actually didn't even know that there was a prerelease version ever available. I don't know how Paket decided to set that as a minimum.

But I hate the idea having to create a new version of my NuGet package without any changes, having release note "nothings changed".

[forki]

@Thorium I still don't really understand the issue. Can you please try to rephrase / elaborate? And what do you suggest to improve in paket?

[matthid]

I think it's about the version range that paket doesn't recognize that 1.0.0 is in fact part of <= 1.0.0

@Thorium To understand the issue a bit better can you give the lockfile that is failing and the build error you are seeing?

[forki]

What? Seriously? That would be a major bug. Am 31.08.2017 6:30 nachm. schrieb "Matthias Dittrich" < notifications@github.com>:

…

I think it's about the version range that paket doesn't recognize that 1.0.0 is in fact part of <= 1.0.0 @Thorium <https://github.com/thorium> To understand the issue a bit better can you give the lockfile that is failing and the build error you are seeing? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2698 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNFGmxioaH21Ot_2uvNMIzbv84_t3ks5sdt-2gaJpZM4PI4sW> .

[matthid]

indeed, but we really need a repro or more info

[Thorium]

1. My project (Owin.Compression) build is not failing. One of my user's build is failing, I'm waiting for more details about his environment...

2. If "Paket doesn't recognize that 1.0.0 is in fact part of <= 1.0.0" is true, that is in the Nuget-package generation phase, not package restoring phase. My project is directly using Owin 1.0 (as dependency) in the paket.lock. I don't know how Paket (template, LOCKEDVERSION, at nupkg creation) has figured out that ">= 1.0.0-prerelease && <= 1.0.0" is good dependency to require for 1.0.

[Thorium]

Answer to previous comment part 1 was that he was using NuGet VS2017 (15.3.3) package manager, which uses by default "DependencyBehavior 'Lowest'" so I think there is not much we can do here.

[forki]

Nuget doesn't detect version 1.0 as member of ">= 1.0.0-prerelease && <= 1.0.0"?

[matthid]

We still need a repro or more information

[Thorium]

Repository that creates the package is here:

https://github.com/Thorium/Owin.Compression

...and @jomonson's repository to restoring a nuget package is here:

https://github.com/jomonson/OwinCompressionDependencyIssue

[forki]

looks like a nuget bug to me

[forki]

https://www.nuget.org/packages/Owin.Compression shows a range that nuget should understand