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.

Most likely, Visual Studio is trying to talk to nuget.org and other services. You can use Fiddler to see what connections are being made.

According to the Package Markdown Support](https://github.com/NuGet/Home/wiki/Package-Markdown-Support) and Packaging Documentation within the nupkg pages maintained by Microsoft, this is an expiremental work-in-progress and the specs are still in review. I would hope Inedo does not implement anything until NuGet settles on a standard, and this has been a work-in-progress for almost 2 years. So, check with Microsoft :)

Make sure to set the Web.BaseUrl setting in Admin > Advanced Settings as well.

We don't have one yet (we're working on the documentation now, expected for the official 5.2 release), but there are examples in ProGet itself for: adding packages: click the Add Package button on the feed overview page after you've added one installing packages: once you have a package in a feed, browsing to it will show you how to install it with pip

Yes, ProGet supports this. However, you will need a paid version of Chocolatey in order to do that https://chocolatey.org/faq#i-would-like-to-be-able-to-offer-my-non-admin-desktop-users-an-option-for-self-service-type-of-installations

In this case, your best bet would be the backup the database, and then only the package files of that feed. In case of DR, your other feeds wouldn't really work (no package files), but your other configuraitn (usernames, etc) would remain.

Unfortunately we can't figure out any reason that Age would be returning an empty string. We're thinking there must be something else... can you share the entire NUSPEC file so we can reproduce it better.

We can't reproduce this; a more likely scenario is that the nuspec in question has an invalid item and is causing an otherwise unknown and unexpected error We would need to full nuspec and the reproduction instructions to better investigate.

Here are the features by edition: https://inedo.com/support/documentation/proget/administration/license ProGet Free is allowed for companies, however that edition only receives "community support" (i.e. this forum).

There was an issue (PG-1208) with semantic version-enabled NuGet feeds and retention policies fixed in v5.0.8 - an upgrade should resolve this.

Yes, that is OK, the differences for each edition are outlined here: https://inedo.com/support/documentation/proget/administration/license

Hi Ryan, Sorry for the delay in getting back to you - we're planning to add this to ProGet 5.2, which currently has a release date of April 11. It should be included in Inedo SDK 1.1.2 (see tentantive spec here). Does that look like it will cover your situation?

Thanks Alana, once I installed the certificate into my 'Trusted Root Certification Authorities' and restarted the docker daemon on my client machine, things are working nicely. Thanks again for your help!

Just to close this post: this was fixed in InedoCore 1.0.12, after diagnosing the issue on a ticket (EDO-5683).