The issue that you linked has since long been resolved; it was a problem with our beta v4. At that time, the problem was the ProGet was "leaking" some connections (i.e. not properly disposing, as your DBA noted). So, if you're seeing the problem now, it's unfortunately not so "simple" of a problem to fix. It basically means that there is some sort of latency between the web/database servers and/or the database is not able to respond to queries as fast as the web server is making them. There's a lot of things that can cause these, from fragmented indexes to low resources on the database server. Do you know what changed recently? Etc. I'm afraid increasing the connection pool likely won't help :/

ProGet is licensed per server, so if you were to have two servers (even if one is just a test / pre-production environment), you would be required to a purchase a separate license. However, if it's just for migration purposes, then you can use your existing license for the migration period.

Basically you need to make sure all three servers have the same machineKey in the machine.config section. OrchardCMS has a nice docs page on it: http://docs.orchardproject.net/en/latest/Documentation/Setting-up-a-machine-key/

Hey! It did solve my problem, thank you so much! Have a great week-end. :)

Make sure you change the proget webservice to run as a user account that has domain access and not use the local system account on the server.

I'm afraid there's not any further configuration. This will happen on any server, physical or virtual, when the SQL Server cannot be contacted. It's usually related to network connections, or the SQL Server is just totally bogged down from other things. See if rebooting fixed it, that will often help.

Please review KB#1161 for instructions on how to update this.

This is by design; it is the responsibility of a package author to license a package, and make sure that it's a standard license. This way, automated licensing monitoring can catch it. However, as you've noticed, this isn't the case for a lot of open source packages. So, in this case, you'll want to use a different workflow. Just create a "approved packages" feed, and promote approved packages into these feeds.

Understood, thanks for the explanation! So this is an issue on the Jetbrains end. We will definitely contact them and see the course of action that's available. Thanks again!

I'm not familiar with Zabbix, but there are two things you can do to check about the status of the components (Database, Web, Service): If the database (SQL Server) wasn't working, or there was a problem with the website configuration, then visiting / will yield a 500 or some other not available message. You can just query the ProGet service run state directly. You could parse the text on the /connectors page or use the native API to get a status of the connectors.

This will be addressed in next maintenance release as PG-1294 . As a workaround, you can access the package directly by version number even without this fix.

Your best way to do this, would be to use the nuget client, and then pull the cached packages to your feed. "Pulling with dependencies" as a feature in ProGet would require implementing every dependency resolution algorithm of every version of every client, including the non-deterministic dependency resolution used by the npm client, and then somehow letting you select the algorithm version and the additional content required by the algorithm (such as .net framework target version).

Thank you Alana. That worked.

Hello Pedro, Docker feeds appear to have been missed when the api user was added for feed authentication. I've filed PG-1295 to fix that. ProGet 5.1.0 is not released on Docker Hub, but you can build the image locally with this command: docker build -t inedo/proget:5.1.0 --build-arg PROGET_VERSION=5.1.0 github.com/Inedo/proget-docker

The Inedo Hub is still in Beta, but we plan to have it support individual components of a tool, such as ProGet.Web. You will also be able to do something like, romp install ProGet.Web to just install/configure the web package. We're also going to be shipping the "legacy" installer (probably won't call it that ^_^), as an alternative option for people who set up automations. For now.. you can use same process.

Use permissions for this. There is a Feeds_OverwritePackage task or something that you can remove, or restrict as you see fit.

Hello Ludovic, This appears to happen when there is no version of your package tagged as latest. To fix it, click the Edit Details button on the latest version of your package and add a tag named latest (all lower-case). I've filed PG-1279 to fix this happening in the first place.

Hello Timofey, I've filed PG-1280 to hide the build metadata from NuGet version numbers when they are displayed in titles.

I had to update the NuGet feeds to the latest version after the upgrade. The packages are pulling in now.

This will be fixed in PG-1273 for the next maintenance release.