Hi @atripp Once again thanks for the quick fix. I was actually worried that something got messed up in our database, while trying to fix the duplicate package issues, but so far everything looks good. Also I should probably start making it a habit of stating that we're still on SQL Server, instead of having you guess. ;)

@kinedax339_3276 great news!! Appreciate the help

Hi @rhowell_8827, Looking at the code in both ProGet and pgutil, it looks like that simplified upload API only supports the distribution argument. We'll add component in the same manner via PG-3172 in an upcoming maintenance release -- ideally next Friday (should be relatively simple). Thanks, Alana

Hi @steviecoaster , Nice suggestion; I made a small change and you can now do pgutil apikeys create feed --feed=* to create such a key. Thanks, Alana

Hi @steviecoaster , FYI - I just a note to the license restriction page; it looks like we don't mention the restrictions on other APIs (delete, scan, etc), but it's something we'll consider next round of docs refactoring. I know we do call it out on the main documentation pages though.

@atripp Hi, thank you very much.

Hi @jonathan-erlich_0694 , Based on the stack trace, there's something wrong with the data being returned via the API from the remote connector. Specifically, one/more of the version objects being returned is missing a name or version property, Based on the URL, the invalid data is at the {repository-root-url}/browser-sync. Here's what it's supposed to look like, based on the public repository at least: https://registry.npmjs.org/browser-sync Thanks, Alana

@atripp now is working :) Thank you!

Hi @parthu-reddy , This can particular occur when there are some issues with the database, such as outdated statistics or highly-fragmented indexes. This script should help fix this: https://proget.inedo.com/endpoints/Public/content/DefragmentIndexesWithRowCount.sql It coudl be something else, but the query that page uses seems to be mostly effected by those. Thanks, Alana

Hi @parthu-reddy , This error means that PowerShellGallery.com is taking too long to respond to that query. You can try increasing the connector timeout; it's 10 seconds by default. Maybe try 20 or 30 seconds? Just a guess. Unfortunately the PowerShellGallery seems to be in a state of abandonment these days and it performs really poorly. It's pretty buggy too. I would consider using a multi-feed, package-approval process to pull packages so you don't have to rely on the gallery's API. Cheers, Alana

Tested in 2025.15, working as expected now - Thank you!

Upgraded to version 25.0.15, and it's working. Thanks.

Hi @dubrsl_1715 I was sure that you must be interested in creating a product that would solve real tasks. Not really :) As a products company, we solve problems that a sufficient number of users would be willing to pay for and that aligns with our overall strategic vision. We also do User-Driven Development, which means we prioritize helping our existing users/customers solve problems instead of adapting the product for nonusers/evaluators like you guys. We don't consider packagist a competitor nor are we currently marketing users to switich; our solution is similar but not an analog. It requires a change to your workflow. The PHP/Composer market is already hyper-niche and I'm not convinced there's enough demand to develop a "versionless" package format (i.e. where a version number cannot be discovered in the manifest file or the package file name) format just for this particular use case (i.e. alternate workflow / simpler migration from packagist). None of the other feed types have this requirement, and it'd be nontrivial to modify our model to support this unique requirement. It would have downstream impacts to features like replication, disk-importing, reindexing, etc. Thanks, Alex

Hi @frank-benson_4606 , Thanks for clarifying, that makes sense. I'm afraid that ProGet does not "crawl" the parent artifacts for metadata; we had considered it, but it's rather challenging to do from an engineering standpoint, difficult to present crawler errors, and fairly uncommon. Thanks, Steve

Thanks! I think the restart of IIS App Pool might have helped. I don't see that failure anymore.

Hi Steve, I will look at an audit report to see if this can be used. Thanks, Frank

Hi @k-lis_1147, Sorry on the slow reply; we did not get a chance to investigate in last release, but it was on the list this week. That being said, it was also an easy fix (didn't anticipate it to be a copy/paste fix)-- and we'll get it via PG-3160 in this week's mainteancne release. Thanks, Steve

Things appear to be normal now, feed integrity checks didn't throw the errors after doing the thorough delete and then re-uploading those packages. Granted the powershell module is no longer getting updates to have parity with the version of winscp and that probably helps too.

@gdivis Too bad I already changed all my keys and updated a lot of Test-VM-Instances in an internal OpenStack. Would have been be MUCH less work. Oh well. Thanks anyway for the info -Fritz

Hi @m-lee_3921, When specifying a package source, the package must be in the same feed; you could specify it using a URL however. { "virtualPath": "common/logo/logo.png", "source": { "url": "http://proget/endpoints/customer-assets/content/ast-logo.png" } Good point on the documentation; download-vpack is for the .vpack file only (i.e. manifest). I'll update it -- Dean