1. Home
  2. Categories
  3. Support
  4. Nuget packages not found during reindex

Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

Nuget packages not found during reindex

  • J

    Is there a chance that Proget is caching files and then searching for files in the wrong directory due to case sensitivity?
    Check out the screenshots below where the package name does not reflect properly in storage path.
    ALSO i have set the connector to NOT cache. But it still caches..
    Using proget 5.3.7 - docker
    For example, i reindex the nuget feed, its looking a package in Syncfusion.Grid.Wpf (however it appears to have stored in Syncfusion.Grid.WPF directory
    pic3.png pic2.png pic1.png

    Let me know if I can provide more logs or something.

    0
  • atripp
    inedo-engineer

    It's definitely possible; we've seen some situations in Cloud Storage where a package's casing changes between versions, and this is the result. But it only impacted replication to our knowledge.

    The cloud storage package stores were modified to fix that, but I suppose it could happen on Linux-based as well, but this is the first report to my knowledge.

    Can you confirm this is happening? It's a very risky change (unlike the cloud storage, which is easy to rollback becuase it's in an extension) that fixes a very small edge case, so we need to be extremely careful in fixing it. It's not clear what's being impacted here, aside from the package verification job...

    0
  • J

    I am hitting an issue when trying to install nuget from proget, it reports the package cannot be found despite reporting having it. If i recall correctly the message may be similar to this

    multiple attempts to download the nupkg have failed. The feed is either invalid or required packages were removed while the current operation was in progress
    0
  • J

    this is definitely breaking builds:

    C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(114, 5): The feed 'https://xxx/nuget/ks-nuget/v3/index.json [https://xxx/nuget/ks-nuget/v3/index.json]' lists package 'Syncfusion.Grid.WPF.17.4.0.47' but multiple attempts to download the nupkg have failed. The feed is either invalid or required packages were removed while the current operation was in progress. Verify the package exists on the feed and try again.
  Unable to find package 'Syncfusion.Grid.WPF.17.4.0.47'.

    Package is clearly there at least on the server, probably searching in the wrong directory
    16042f2a-fb4e-4ca6-9c52-88549c6c429b-image.png

    0
  • atripp
    inedo-engineer

    I see; it seems the problem is the casing change from v12 to v17 of the package.

    I assume you are't using both at the moment? As a work-around, can you try deleting v12 of the package, then renaming folder to WPF instead of Wpf?

    Will that work?

    0
  • J

    we are actually using both versions, some of our legacy applications appear to be pointing to the 12.x version. I copied the package into Wpf folder and had to modify the names of the actual package for it to work. The casing of the package had to match as well for it to work.

    7f8f6f35-335a-4ba2-82fd-9c2ac799c1c7-image.png

    Please work on a fix for this. I think this type of mucking around in the packages directory may pollute the contents.

    0
  • atripp
    inedo-engineer

    Thanks; so just so I understand, if you made a properly-cased version of the v12 package file, it worked, for both versions?

    It's not ideal, I know. But this is situation must be extremely rare (first report in many years), and fixing it is costly/risky, so we need to weigh cost/benefit (especially when there are a lot more valuable things we can could improve in the software) against a workaround.

    0
  • J

    So it looks like Proget is not even searching Syncfusion.Grid.WPF directory despite most of the new packages going into that.

    I deleted Syncfusion.Grid.Wpf directory and it couldn't find the package despite being a copy inside Syncfusion.Grid.WPF directory.

    C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(114, 5): The feed 'https://xxx/nuget/ks-nuget/v3/index.json [https://xxx/nuget/ks-nuget/v3/index.json]' lists package 'Syncfusion.Grid.WPF.17.4.0.47' but multiple attempts to download the nupkg have failed. The feed is either invalid or required packages were removed while the current operation was in progress. Verify the package exists on the feed and try again.
  Unable to find package 'Syncfusion.Grid.WPF.17.4.0.47'.

    What made this work was copy/move and rename 'Syncfusion.Grid.WPF\Syncfusion.Grid.WPF.17.4.0.47.nupkg' to 'Syncfusion.Grid.Wpf\Syncfusion.Grid.Wpf.17.4.0.47.nupkg'

    If no cache is set for the connector, none of this should technically matter, correct?

    0
  • atripp
    inedo-engineer

    Thanks, got it. An annoying work-around for sure, but it somewhat makes sense, because the package name must be decided based on the first package in the list? I don't know... but the right-answer is to store everything as lower case and have a fallback for mixed-case (which is what we did in the cloud storage).

    If no cache is set for the connector, none of this should technically matter, correct?

    The problem is occurring when the package is being loaded some disk, so it would impact Cached and Local packages, but not Remote packages.

    0
  • J

    What are the chances of storing everything in lowercase getting added? Can the same fix be applied to the cloud storage bit apply to the Linux setup?

    Has anyone reported that disabling cache connector still caches the packages locally for nuget? If this was working I guess I wouldnt be affecting me cause I have cache off.
    Despite cache off, the cache size has been increasing, such as the Syncfusion.Grid.WPF being downloaded locally..
    21610dbf-c53f-40b5-bd6e-b8751dda5112-image.png

    0
  • J

    I want to add that after the manual change, when I did a reindex it seems like Proget detected it as an invalid package and removed it (i checked the delete option)
    c2de0428-c205-4693-84e1-940bb01e55f4-image.png

    0
  • atripp
    inedo-engineer

    I see; that makes sense, the re-indexing would delete it.

    Hmm, okay, I just thought about another work-around instead. Please download v12 package, edit the .nuspec file, rename it to be cased like the others, and then upload it? This ought to solve it, as well.

    It's definitely a bug we can look to fix, but thus far it's impacted just a single user on a single package in several years so far. It's a high-risk change, and we have a lot of things on the backlog that add more impact/value to the users.

    0
  • J

    Did a quick look in our packages directory, looks like Syncfusion Inc has done this to other packages as well with the case rename, got 10+ packages that have different cases :(
    217aca5c-095d-4bdb-ab44-3fe131d6016f-image.png

    0
  • J

    are there any other ideas to fix this?
    new packages are going into the wrong folder and i have to copy it to the .Wpf one from .WPF
    new package:

    C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(114, 5): The feed 'https://xxx/nuget/ks-nuget/v3/index.json [https://xxx/nuget/ks-nuget/v3/index.json]' lists package 'Syncfusion.Grid.WPF.18.2.0.54' but multiple attempts to download the nupkg have failed. The feed is either invalid or required packages were removed while the current operation was in progress. Verify the package exists on the feed and try again.
  Unable to find package 'Syncfusion.Grid.WPF.18.2.0.54'.

    e9a90edf-11d9-4467-8103-dfd249d5c642-image.png
    Running this command every time it breaks something cause a new package is not feasible.
    Technically the package shouldnt be caching, so will PG-1804 fix this?

    0
  • atripp
    inedo-engineer

    Hello; good news, we can now fix this as part of SDK-64, which will ship in ProGetCore, a new container that will contain the .NET5 version of ProGet that's designed to replace the mono stack.

    We're planning to ship a public technology preview by the end of next week (as part of 5.3.11), and the ProGetCore container will eventually replace ProGet container (which will become ProGetMono). This will happen well before November, but we don't know when.

    PG-1804 will fix the caching problem you identified, however.

    0
  • J

    this is excellent news, i am looking forward to this fix.

    thank you.

    0
  • J

    still looking forward to this in 5.3.11, but wanted to let you know release 5.3.10 had a fixed a bug that was caching unintentionally. Since these packages I do not intend to cache, the case sensitivity issue is not affecting me for now.

    0 atripp 1 Reply
  • atripp
    inedo-engineer

    @jyip_5228 FYI, as part of ProGet 5.3.10 release, we shipped the ProGetCore container image as well.

    You can follow the normal steps in the Linux and Docker Installation Guide to install/upgrade, but just use progetcore for the container instead of proget.

    Aside from support for the Lucene-based Maven feed indexing (in progress), it seems to be feature complete. And of course, if there are problems, you can switch back to proget:5.3.10 or downgrade as needed (no database schema changes).

    For example, docker pull proget.inedo.com/productimages/inedo/progetcore:5.3.10

    0
Log in to reply
 
Inedo Website Home • Support Home • Code of Conduct • Forums Guide • Documentation