Wrong versions getting picked up by Octopus from feed due to Nuget bug

Legacy Uncategorised
1

Hi

Im seeing Octopus not registering the latest version of a package when creating a new release (see screenshot)
I tried rebooting the server but the issue persists.
I can force a higher version and octopus will fetch and deploy it (see screenshots).
I have verified this behaviour with Nuget.exe (see screenshot).
If i update to latest version of Nuget.exe, it works (see screenshot).

The behavior is consistent if I change back and forth between the 2 version of nuget.exe.
So this IS a nuget issue.

I do not know which version of nuget.exe or nuget.core you are using but unless you have seen this behaviour before, then I believe that this is a bug which must be fixed asap :).

Kind regards
Christian Mikkelsen

SS1.PNG

SS2.PNG

SS3.PNG

SS4.PNG

SS5.PNG
SS5.PNG764×110 4.81 KB

SS6.PNG

2

Hi Christian,

Thanks for getting in touch. Which NuGet server are you using, and roughly how many packages do you have in the server?

Paul

3

Hey Paul

Thanks for getting back so quick :slight_smile:

We are building in the cloud using AppVeyor.
AppVeyor hosts the feed and the feed currently contains just about 2017 packages.

Internally we are using the Klondike nuget/symbols source server with Lucene index, but we only move packages to this feed once they are in production using Octopus. So its irrelevant in this case.

I tested with nuget.exe on the command line and the strange thing is that the newest version of nuget.exe easily can detect and install the correct version, but the “old” nuget.exe cannot and displays the exact same behavior as I see in Octopus.

I have walked through the newest version of the nuget source code and will try doing the same with older version tomorrow, hopefully identifying the difference in behavior.

Do you think it might be an AppVeyor issue?
I have previously mentioned for them that they should use something like Lucene in their feed, but since then performance have been fine.
I have very good contact with them, but I need a bit more concrete place to start if you think they might be the cause :slight_smile:.

Kind regards
Christian Mikkelsen

image001.jpg

4

Hey Paul

Thanks for getting back so quick 

We are building in the cloud using AppVeyor.
AppVeyor hosts the feed and the feed currently contains just about 2017 packages.

Internally we are using the Klondike nuget/symbols source server with Lucene index, but we only move packages to this feed once they are in production using Octopus. So its irrelevant in this case.

I tested with nuget.exe on the command line and the strange thing is that the newest version of nuget.exe easily can detect and install the correct version, but the “old” nuget.exe cannot and displays the exact same behavior as I see in Octopus.

I have walked through the newest version of the nuget source code and will try doing the same with older version tomorrow, hopefully identifying the difference in behavior.

Do you think it might be an AppVeyor issue?
I have previously mentioned for them that they should use something like Lucene in their feed, but since then performance have been fine.
I have very good contact with them, but I need a bit more concrete place to start if you think they might be the cause .

Kind regards
Christian Mikkelsen

5

Hi Paul

Updated to latest Octopus version yesterday.
Im still experiencing this issue.
Any progress?
Are you guys updating nuget.exe/nuget.core in Octopus in an upcomming version?

6

Hi Christian,

We’ll be updating the NuGet version in Octopus 3.0 (so we can make sure it doesn’t break anything else).

For now, you might need to find an alternative NuGet server. Perhaps you can push to the built-in Octopus repository, or an externally hosted NuGet.Lucene or MyGet server?

Paul