Thanks @stevedennis , I'll have a poke at 2025 and see if it's good to move to. It does appear to be visual as we can search for tags via choco API etc, but not via the GUI search which I would have assumed called the API. Yeah the total downloads is the "Downloads" column on the main page for each feed. So it would be a sum of all packages downloaded AFAIK. It's not super critical but is a good metric for us

That's the intended/expected behavior of repackage. The use case is CI/CD workflows, so you would do something like: Create w.x.y-ci.z Repackage to w.x.y-rc.z Repackage to w.x.y Retention policies would then clear out old -ci and -rc packages. I believe that display bug has been fixed in ProGet 2025; I remember seeing it listed as a bug discovered during testing. But in any case, it's in the package history as you can see.

Hi @stevedennis, You're right, they are blobs, however the directory structure itself is still has value and reflects the layout of the package e.g. name/version/export/package etc. Here's a screenshot of what we see: So even though some of the folder/files have hashed names, the overall structure with export/, package/, and files like conaninfo.txt are quite useful when trying to inspect/debug packages. Something like this in the ProGet web UI would be much appreciated. Thanks!

Hi @mmaharjan_0067, This is not a trivial request and would require database changes, new API endpoints, and of course pgutil changes. We will put it on our ProGet 2026 roadmap for future consideration -- hopefully some other users will chime in! Thanks, Steve

Hi @mhelp_5176, When hosting via the Integrated Web Server, you will need to update the account the service is running as. As long as the GMSA is a db_owner on your database, then "Integrated Security=true;" in your connection string will use that account. As for installs through the InedoHub with "Integrated Security=true;" , it will use the account of the person running InedoHub when connecting to SQL Server during the install, so that account will need DBO on the ProGet database as well. Thanks, Rich

Hi @misael-esperanzate_5668 , I'm afraid we simply can't reproduce this. Here is what we do: New Maven feed w/ Maven Central Connection Download Index Navigate to /feeds/marvin/org.hamcrest/hamcrest-core/1.3 All files will show up in the list because the index file is downloaded; if the index file was not downloaded, only the pom file will show. But the behavior is the same either way. The artifacts download with no issue, as expected: curl http://localhost:8624/maven2/marvin/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar curl http://localhost:8624/maven2/marvin/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.pom They download in any order just fine, and I can delete them from the ProGet UI. There is no case that we can have a "file vanish" as is happening to you. The 404 error you keep getting is expected if there is a cached entry without a file. There is really no other way we can imagine to get that error. It's very common on Windows for files to "suddenly vanish" when you have anti-virus tools running --- a .jar files suddenly being written to disk will often trigger a quarantine action. ProGet obviously cannot detect nor prevent this interference. You may be able to use a tool called ProcMon to monitor for interference: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon Otherwise, you may wish to just set up a AWS Lightsail sandbox, which can be done for pennies: https://docs.inedo.com/docs/proget/installation/proget-how-to-install-on-aws-lightsail That will allow you to compare/contrast behavior. Thanks, Steve

Hi @michal-roszak_0767 , You can just click "edit" on an API Key in the UI to change the date or secret value. However, if you have "Cryptographic hashing" enabled, then you will need to delete the key and recreate it to change the value. Thanks, Steve

Hi, @rhessinger! Thank you for looking into this. I will do some retesting as soon as the 2025.2 is released. Thanks, Petter

Hi @mwatt_5816, Thanks for all of the detail. I have fixed the code, BM-3982, for this template and it will be released in the next maintenance of BuildMaster 2024.0.7 on Friday. Thanks, Rich

Hi @parthu-reddy , These indicate that your network stack is being overloaded. npm can do this, as it's sending thousands of simultaneous requests to your server. Each of these requests require multiple database connections (network) and requests to remote registries (network). If you're using load balancing, you'll want to tweak the configuration to do rate limiting. For example, in npm it's this: https://blog.nginx.org/blog/rate-limiting-nginx Hope that helps, Steve

Hi Marc, Thanks for the note! That file is actually a sort of cross-platform way of storing symbolic links. BuildMaster also includes all the binaries needed for agents on both Windows and Linux, including .net runtimes for all three. In order to save space we deduplicate identical binaries from the agents. We use a simple json file instead of proper symlinks because we use the same file on Windows/Linux and it's easier this way. All the paths in the file have historically used Windows path separators due to how we generate it, and we convert those in BuildMaster at runtime to the proper format.... or at least we were supposed to. At some point there was a regression added that caused this to not happen when updating from Linux. Anyway, this will be fixed as BM-3981 in the next release :)

Hi @jfullmer_7346, Thanks for the detailed recreation steps on this! I was able to recreate the issue and created a ticket, PG-3018, to track the fix. This is expected to be fixed in ProGet 2025.2 on Friday of this week. Thanks, Rich

Thanks @rhessinger, that clarifies things, and I can move on. Best regards, Stefan

Hi @lukas-christel_6718, Sorry for the delay on this. We just pushed an updated pgutil that will now skip over any invalid versions. Thanks, Rich

Hi @m-karing_2439, It looks like this is a network-related issue: "Cannot determine the frame size or a corrupted frame was received." There are no changes in ProGet 2025 that would cause something like this, but it's possible that a firewall or something else is interfering with the communication. The executable name changed from ProGet.Service.exe to proget.exe, and we've seen some "anti-virus" tools require a new execption be made. No idea why it would work for PyPi, however. Hope that at least points in the right direction. Thanks, Steve

Yes - they are "self-connectors". We've now bought an externally signed certificate, as it seemed like the simpler option (the in house cert option was causing other issues too). However that hasn't resolved the issue with the self-connectors. However, I've just edited those connectors manually to use http rather than https, and that has resolved the issue. But It's not really an ideal solution. So it looks like from inside the docker container it's still not "trusting" the externally signed certificate.