NuGetV2-OData: retrieve versions in descending order

[cdrnet]

Some of the NuGet servers have broken feed paging. This PR changes the order such that newer packages are returned first (Publish date, descending). In case of broken paging, getting only newer versions seems less of an issue than getting only older versions. This is in particular relevant when using the update command without explicitly specifying a version (which downgrades to older versions otherwise). With this change, the request is also closer to how the NuGet Package Explorer queries all versions of a package.

[cdrnet]

Verified against Artifactory.

[cdrnet]

@forki have we had issues with other feeds (e.g. proget) in the past where this change could potentially cause problems? (If so, I'd expect NuGet Package Explorer to not work with them either)

[forki]

I never tried that. We can try it and if things break then we restrict this change to artifactory

[cdrnet]

Does Paket already understand what server it is talking to?

[forki]

We only know the url

Am 09.11.2016 09:02 schrieb "Christoph Ruegg" [email protected]:

Does Paket already understand what server it is talking to?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2008 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNHTWQVWj6jT202uN9Zq_5nB02YJDks5q8X4pgaJpZM4KsNLB
.

[cdrnet]

If we ever need it (which I hope not), it actually tells so in the HTTP header:

HTTP/1.1 200 OK
Server: Artifactory/4.10.0     // it's actually 4.14.1 #wtf
DataServiceVersion: 2.0
Content-Type: application/atom+xml;charset=utf-8
...

Technically we could leverage this to skip the v3 trials there (which it does not support), but let's not complicate things unnecessarily...

[cdrnet]

So, can we give it a spin? :)

[forki]

yes please try it out

[cdrnet]

Thanks, v3.27 works well for me. Suddenly commands like outdated give sensible output also on internal feeds :).

I don't have any other V2-only third-party feeds I can test against to verify myself unfortunately.

[Vilmir]

@forki @cdrnet how shall we fix server-specific issues with OData?

Optional source brand config

We could allow users to optionally specify their source brand in the paket.dependencies:
source artifactory https://artifacts.sonova.com/artifactory/api/nuget/chinook-production

Source brand probing

Before querying the feed, a dummy query is sent in order to catch up a trace of the source brand in the response.

Then, when the source brand has been identified, specific fixes can be used at the right place.

Option 1 sounds better to me as we do not add yet another HTTP get before querying the feeds. It is also potentially a less buggy behavior. Users that do not actively specify their source brand will not be impacted.

[forki]

tbh I'm fine with URL guessing.

[Vilmir]

You mean trying to determine the brand by parsing the URL string specified as source?

[forki]

yes. we do that already for nuget.org and myget and things like that

[Vilmir]

That would work fine for public servers where the domain name reflects for sure the server type, but for Intranet private servers it is not true at 100%
Our company chose to create service names by their functions, decorrelated from their brand:

• artifacts.sonova.com: today is actually Artifactory, may migrate to a less buggy product
• symbols.sonova.com: ProGet and it will probably stay ProGet for a while. Because it just works for debug