This should be fixed in v2.2.4, but the issue did not get added to GitHub - I'll correct that.

Please carefully follow the Getting Started with NuGet Feeds in ProGet and Visual Studio tutorial. You need to use the API endpoint URL (shown to you within ProGet's Feed page), not the URL that you at the top of your browser. The /feeds URL is intended for use by a web browser, and the /nuget URL is used for an API (i.e. Visual Studio).

Great to hear it got fixed. Thanks !

Hello Damian, I believe this is due to ILIB-60, which is caused by a bug in Mono.

This is also being discussed here; long story short, this is a bug in Microsoft's PowerShell Gallery (and in the packages) in that they have two conflicting version numbers, and sometimes one is used, sometimes the other is used. The docs have been updated for now: https://github.com/Inedo/inedo-docs/commit/10c42c3ad546ac2feb4748b7736db06567c7a6d6

Hello Simon, I wasn't able to find any information on any standardized way to designate a license in a Dockerfile. I believe the license field in the Docker image pages in ProGet is not filled in by anything.

This is on the all versions page, just click "Traditional Installer".

That message is expected, if it's already an updated database. Please check out the restore procedure outlined in Backing Up ProGet instructions

Thanks Justin; we definitely need to improve docs. I just made a change to it now to clarify this better: https://github.com/Inedo/inedo-docs/blob/master/ProGet/feeds/maven.htm

ProGet does not push packages; but you can use a tool like BuildMaster to help build a pipeline for your own nuget packages, and push to different nuget servers along the way.

Just seen that .18 has been release. Tested and working. Ignore above.

UPDATE: this was resolved through our ticket-based support. The underlying issue was "Unable to reach credential server" s3, and it was related to how the credentials were configured in IAM.

Hello Attila, If you run docker inspect proget -f '{{json .Mounts}}', does it include /var/proget/extensions as both the source and destination of one of the bind mounts?

Keep in mind that retention rules work on an AND basis, so when you select: Delete cached connector packages Delete old versions (all except latest 30 versions) You get only packages that match BOTH of those rules: Only delete cached packages. Never delete the most recent 30 versions of packages. I'm guessing that your packages don't match BOTH those rules;

There is currently no such healthcheck URL; you could use a static resource (like a logo, /resources/images/layout/logo.svg) to see if the web server is responding. That request should be very fast.

If you want developers to always be able to use any version of a package, then you should configure a connector to that remote resource. Then, they will always be able to download the latest version of the packages they need, and ProGet will cache those packages.

There is nothing to re-index. If you see it in the web, then it's already indexed. If the packages appear on the web page, then they will appear in the feed. You can manually inspect the feed with the API if you'd like, or by using a tool like Fiddler or something to see the requests.

Please note that retention policies are a paid feature. Although rules can still be configured in the free edition, they are always executed in dry run mode in ProGet Free. In addition, when multiple options are specified, then only packages that meet all of the selected criteria are considered. Please review the retention rules for more information Otherwise, the best place to look would be the retention logs, to show you what packages were considered.

There was a UI change; these are listed under "Containers" in the top UI.