Thanks very much, Scott. You helped me by mentioning that the feeds themselves also need to support SemVer 2.0. I wasn't aware of that fact. So I just migrated our feeds an now everything works fine.

Hi Alana, Thanks for the information. I've reinstalled ProGet and IIS several times and at attempt four it suddenly worked fine. So I'm not touching the setup anymore and will keep it as-is now! Thanks, Eelko

Please check the Symbol and Source Server; basically you will want to use a symbols feed. The /symbols endpoint is not a Nuget feed, so you can't push packages to it.

Hello Mickael, ProGet does not support SSL on its own. However, if you have a reverse proxy like Traefik or nginx, you can terminate SSL in the reverse proxy and forward the connection to a locally-bound HTTP address. Here's the documentation for setting up SSL Traefik and nginx: https://docs.traefik.io/user-guide/examples/#http-https-with-sni https://nginx.org/en/docs/http/configuring_https_servers.html

A GitHub repository contains only code, so you will want to treat it as if it were a package you wrote yourself. This means download the source code, compile it, package it per the appropriate packaging method (e.g. npm, NuGet, etc), then upload that package to ProGet. You can use something like BuildMaster to automate this workflow.

Get in touch direct,happy to work toether on POC/implementation

Are you granting "Anonymous" the permission to view/download packages? If you remove that from the User Tasks page, then authentication would be required.

I'm not sure why that response says that (I believe it was written when ProGet was still in Beta), but it is in fact inaccurate. The rules for closed testing or DR instances is that a separate license is required as per the licensing agreement: https://inedo.com/proget/license-agreement In order to clarify this with some examples, I've added the following documentation that will release when 5.2 goes live: https://github.com/Inedo/inedo-docs/blob/proget-5.2/ProGet/administration/license.md#examples

@valeon @miles-waller_2091 @olivier @It-purchasing_9924 @entro_4370 Took a bit, but CRAN (R) feeds have arrived https://blog.inedo.com/inedo/introducing-cran-feeds-in-proget/

Thanks for the suggestion, I've filed this to be done here: https://github.com/Inedo/inedox-inedocore/issues/112

You can host ProGet in the cloud (AWS or Azure), but Inedo does not offer hosting of ProGet at this time. It is on our future roadmap, but there is very little interest it based on previous research.

The steps are outlined here: https://inedo.com/support/documentation/proget/advanced/cloud-storage

Thank you, in my case this is an internal Nuget package that is deployed directly to Proget. I unlisted a package version in Proget and I see the listed property is false via fiddler but it still shows up in a visual studio search. By the way, I just created a new topic for my issue here. https://forums.inedo.com/topic/3514/unlisted-package-version-still-shows-up-in-visual-studio

I found my mistake I had to specify the "Feed API user" in the API Key configuration.

I took a while to get back to this thread, but here goes: Today we upgraded to the MSSQL backed version of ProGet, that is currently on the Docker hub (5.2.9.11), and most of it went smooth. However, when restoring all the packages, I did get the unresponsive errors again. But this time the server came back and we could see the log messages. After changing the connection string, things seem to be more stable now when doing a full restore. The new connection string has this appended to it: "Max Pool Size=200;" Hopefully this version keeps us happier, as the old version needs a reboot every other day.

You can safely do all of those things :)

Thank you Stijn Peeters, you are spot on! After I performed the migration on our Default feed this morning all packages are showing up as expected when searched for - wahoo! Thanks again!

Thanks. That solved it.

Oh I see, you're migrating a legacy NuGet feed! Sorry I misunderstood. With the number of packages you have, a database transaction will put a strain on your database server, which is most certainly where the problem is. Instead, why not back up the database beforehand, then run the migration without verbose logging and a transaction.

I see; in this cases, go to Advanced Settings, and change the base url property.