That's a bug affecting NuGet feeds - we're publishing a hotfix release today (4.7.6) and will include a fix for this.

ProGet does not currently implement the "_catalog" endpoint currently, which Octopus uses to detect the registry version. It's on our list, but we do not have an ETA for it now.

We test with the latest version of Posgres, but I haven't heard of any issues with 9.4 or newer. This ought to recreate the missing tables in your database: CREATE TABLE "Licenses" ( "License_Id" SERIAL NOT NULL, "External_Id" VARCHAR(50) NOT NULL, "Title_Text" VARCHAR(200) NOT NULL, CONSTRAINT "PK__Licenses" PRIMARY KEY ("License_Id"), CONSTRAINT "CK__Licenses__External_Id" CHECK (RTRIM(LTRIM("External_Id")) <> ''), CONSTRAINT "UQ__Licenses__External_Id" UNIQUE ("External_Id") ); CREATE TABLE "LicenseUrls" ( "License_Id" INT NOT NULL, "License_Url" VARCHAR(400) NOT NULL, CONSTRAINT "FK__LicenseUrls__Licenses" FOREIGN KEY ("License_Id") REFERENCES "Licenses" ("License_Id") ON DELETE CASCADE, CONSTRAINT "CK__LicenseUrls__License_Url" CHECK ("License_Url" NOT LIKE 'http://%' AND "License_Url" NOT LIKE 'https://%'), CONSTRAINT "UQ__LicenseUrls__License_Url" UNIQUE ("License_Url") ); CREATE INDEX "IX__LicenseUrls__License_Id" ON "LicenseUrls" ("License_Id"); CREATE TABLE "LicenseRules" ( "LicenseRule_Id" SERIAL NOT NULL, "Feed_Id" INT NULL, "License_Id" INT NOT NULL, "Allow_Indicator" YNINDICATOR NOT NULL, CONSTRAINT "PK__LicenseRules" PRIMARY KEY ("LicenseRule_Id"), CONSTRAINT "FK__LicenseRules__Feeds" FOREIGN KEY ("Feed_Id") REFERENCES "Feeds" ("Feed_Id") ON DELETE CASCADE, CONSTRAINT "FK__LicenseRules__Licenses" FOREIGN KEY ("License_Id") REFERENCES "Licenses" ("License_Id") ON DELETE CASCADE ); CREATE INDEX "IX__LicenseRules__Feed_Id" ON "LicenseRules" ("Feed_Id"); ALTER TABLE "Feeds" ADD "AllowUnknownLicenses_Indicator" YNINDICATOR NULL; DROP TABLE "FeedLicenseUrls" CASCADE;

Please see Cloud Package Stores for more information on how to configure these.

This is addressed in 4.7.6; was a regression.

Yeah, I have the same problem, if I change TargetFramework from net45 to net452 they show up.

The url is wrong, and we will update this in the next maintence release

Thanks Dean, upgrading to 4.7.3 has solved the issue!

Figured it out. It's not the user running the installation that needs db_owner membership. It's the SQL user (i.e. progetuser) created in the original setup that needs temporary db_owner membership for the upgrade process. Thanks.

Thanks for the bug report. This will be fixed in v4.7.2, which should be released today. To upgrade, see the "Upgrading to a new version" section of this KB article: http://inedo.com/support/kb/1100/getting-started-with-proget-for-linux Basically though, when the container starts up it makes sure the database schema version is current, so all you really need to do is run the new container and point to the same data.

You could look at the event log under Admin > Events and possibly see when/who deleted it, but there's no way to know "why" it was deleted. ProGet will not automatically delete package versions unless you specify that in a retention policy, or if they're removed from disk or database.

Ok, I've found the problem: Docker image manifests have a really complicated way to compute their digest: Parse the manifest as JSON, keeping key order. Remove the "signatures" key of the root object. Re-encode the new root object as JSON, with 3(!) space indents, LF newlines, and no newline at the end. Compute a SHA256 hashsum. The problem was that on Windows, ProGet re-encoded the new root object with CRLF newlines. This is fixed for the next version. (4.7.7)

Please note that this (or any multi-node) installation requires a ProGet Enterprise or ProGet Load Balanced License to be purchased. ProGet Basic and ProGet Free only permit a single server to be used in a single installation. That said, we recommend IIS because it's the easiest to support (by your own network admin team) and has many configuration options. In theory, you could probably use the integrated server. A HA configuration ought to use a SQL Cluster, otherwise you have a single point of failure.

I tried to use the docker API, however I'm having problems accessing it For example, according to the API documentation: GET /v2/<name>/manifests/<reference> Should get the signature, however using this call: curl -H "Accept: application/vnd.docker.distribution.manifest.v2+json" -X GET -vvv -k https://<host>/<repository>/v2/<image>/manifests/latest Returns not found. What is the correct way to call v2 API from a proget docker repository ? I couldn't find any documentation about it. Thanks Francisco

Please see the ProGet feature comparison. There are no limits to the number of feeds.a

Glad that worked! I created an issue for this; we should get this behavior a little more intuitive in an upcoming maintenance release.

We will have full support for Windows containers in ProGet 4.7.10, which is scheduled for release tomorrow.

OK, I will upgrade to the latest version. It turns out the ProGet service wasn't running. I hadn't even realized it because the Web site and NuGet/NPM feeds were working normally. Starting the service was all that was needed to get those tasks running. Thanks

thanks we managed to find it as nuget was packing the release and debug files over the top of each other for some stupid reason in just the packages generated for this project. no idea why it did not affect any other solution on our build server

Retention policies are available on paid versions of ProGet, so "ProGet Basic" and up; you can see current ProGet Pricing here.