Hello Scott, This is done for 1-part repository names to match the behavior of Docker Hub. You should still be able to access the container without library/; that is, this should also work: <proget_server>:80/<container_feed>/<container_name>:<tag>

The groupName refers to the package's group name, and it's optional. A universal package is identified by group + name + version. The files do need to be artifacts; that's what will be zipped up and sent to ProGet.

After doing the steps in the links, I was able to remove and re-install proget (using offline installer). After that, Hub still didn't work, so I tried running the online-installer which downloads the Hub at the beginning of the install and that seemed to fix the Hub. Thanks for your help Dean.

Thank you for the report, this is resolved via: PG-1447

That's awesome, thanks!

Hello Eric, I think Docker requires at least one . in the hostname, and it's trying to access the default Docker hub. Another way that might work would be to add the port number to the hostname: <server name>:443/<feed name>/library/redis (the library part is optional to match the Docker hub, so <server name>:443/<feed name>/redis should also work)

Sorry on the delayed response; PG-1472 should fix the version selector failing for packages with partially missing snapshot metadata, like maven-archetype-plugin, which was used to test.

Unfortunately this was a regression present in 5.1.19, but has since been fixed in 5.1.20 which was released earlier today.

Upgrading to v5 seems to have fixed this

The Docker Client does not support integrated windows authentication; as a work-around, you'll want to set up a second ProGet site (different port or host name) in IIS that points to the existing folder but doesn't use integrated authentication.

Hello Ta, I was unable to find any mention of what metadata keys the Docker Hub looks for for those values, but I've filed PG-1443 to display all labels without any special formatting.

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