Hi Dean, we noticed that when performing an "npm install" against ProGet it will successively open ~1000 sessions. We tried a couple of values for Web.ConcurrentRequestLimit under "Administration --> Advanced Setting" (20, 50, 100, 200) and found out, that when using 100 we get the same (or even better) performance for an "npm install" compared to registry.npmjs.org. We're not exactly sure how Web.ConcurrentRequestLimit works but we assume that it has some relation to the default pool size for the SQL Server connection used by ProGet, which also seems to be 100. I just wanted to let you know, that by setting Web.ConcurrentRequestLimit to 100 the performance of "npm install" is back to normal. Best, Andreas

FYI - we plan to fix this in ProGet 2023.32 via PG-2613

Hi @scott-wright_8356, I looked into this further; for Maven feeds, the Connector Health Check simply queries the downloaded index. If there is no downloaded index, then it reports back as healthy. If there's an error with the index, it reports an error. However, most maven repositories don't have a downloadable index. Anyway the health check is not very useful, and we plan to revisit the functionality in the future, since there's really no way to determine if ProGet can download an artifact unless you know the exact name. Thanks, Alana

@appplat_4310 thanks for the update! We also applied the patch to the next maintenance release, so you shouldn't have any issues going forward then!

@atripp thanks for confirming.

Hi @scott-wright_8356 , Thanks; it sounds like the underlying issue is indeed Google Android connector you added. I don't have an information or idea on why that might be the case... some third-party repos (Maven, PyPi, NuGet, etc.) are just really slow and buggy. ProGet is basically acting like a proxy server here, so "garbage in, garbage out" applies - if the connector is slow and error-prone, then you will experience slowness and errors. Sometimes third-party repos will create packages that don't follow the specifications but just happen to work in certain versions of clients. That could be what's happening here. In cases like that, we can really only address those on a case-by-case basis, and we'd need to know exactly how to reproduce the error and investigate it later. Best, Alana

Hi @sebastian, That option can be ignored. We have decided to remove that option from the feature because it was only something that changed a UI color and had no real affect on the operation. It looks like we missed it in that UI. We will remove that in an upcoming release of ProGet. Thanks, Rich

Hi @scott-wright_8356 , You can change if you'd like, I'm not sure if it makes any difference with .NET6+ applications. Cheers, Alana

A possible solution to this is to use Extended Properties in SQL. That way you can check the version of the files in the upgrade and not re-create them when they have already been updated?

When you say Web Server Windows Service, I think you should put the account against the ProGetAppPool Identity. We are running as an integrated SQL connection, and the account is a DB Owner. Both the APP Pool and ProGet Service run as this account. We added the following to the connection string Persist Security Info=False;Integrated Security=true;

Just to close this thread off. I tried below but no joy: Rebooting server several times Server is not under any load All other feed related API's worked fine Re-installed proget Resolved: Re-installed proget and re-created DB

Hi @jw , thanks for pointing this out! I added a note to review/investigate this in our run-up to finalizing ProGet 2024.

Hi @philippe-camelio_3885 , We haven't run into any of these issues in our testing, but this error is a "generic database timeout", which is implying that "something" is going on with the database. That's the only information we have, "something". To troubleshoot this, you'll need to use some of SQL Server's performance/activity monitoring tools to spot what's going on at the time. It could be anything from outdated statistics to a missing index to a bad query. Or who knows. Best, Alana

Hi @philippe-camelio_3885, We do not support "sub-path content/URL Rewriting" in any of our products and strongly discourage even trying. It won't work and will just lead to lots of wasted time and headaches, since everything from javascript ajax requests to CSS background images to cookies assumes a well-known root path of / for the application. Best, Alana

Hi @mahdy-merry_6333 , It's possible, and you can do this by creating a second feed that effectively proxies the first feed and uses disk storage. You could use a Connector on the two feeds or REplication. Cheers, Alana

Hi @jw, Thanks for letting us know about these. To answer your questions: This is an issue with the order of how we delete the projects and their child items. If you delete all the builds first, then the project can be deleted without issue. We will fix this as part of PG-2596 that will be released tomorrow in ProGet 2023.31. This is an oversight on our part. We will get delete buttons added to the Edit Project Settings and Edit Build Settings page also as part of PG-2596. Thanks, Rich

Hi @matt-wood_5559 , Looks like your account was added to My Inedo incorrectly due to a human error (someone manually added it on our end since you had been talking to sales)... but it looks like its already been corrected, and you have a working key to use now. You shouldn't have any issues going forward. Cheers, Alana

@atripp We applied the script, can confirm that we are not getting the error anymore. Thanks!