Ah, I see; please note that we do not support v1 feeds (they were already obsolete when we build ProGet in 2012) and we have no intention to. Suggest you push packages from TeamCity to ProGet instead.

Team member here. I'd like to let you know that we've moved to the public npm registry. See Retiring the Progress NPM Registry.

Hi @atripp Just to let you know that I just upgraded version 5.3.24 and can confirm that this issue is now resolved! Thanks so much for all your help! Thanks Simon

Hello John I upgrade to version 6.2.5b8. The sync is working. I get all the servers, and roles, BUT I have seen a weird behaviour I had 3 env defined in Otter INTEGRATION DEVELOPPEMENT PRODUCTION and only two were sync in Buildmaster. DEVELOPPEMENT PRODUCTION The servers assigned to the missing environnement in Otter were assigned to the "none" environment. In OTTER, I assigned INTEGRATION as child of DEVELOPPEMENT, ran a sync and INTEGRATION appears in Buildmaster as child of DEVELOPPEMENT I removed the link to DEVELOPPEMENT, ran a new sync. Strange isn't it ? But now, every seems to works fine until the next bug Thanks Best regards PhilippeC.

I also confirm I didn't get any more timeouts on the latest version. Very good!

Hi @apxltd, thanks for the insights! I half expected this to be way more complicated than I had hoped for, but one can dream...

Hi @aneequaye_1868, I apologize, I was speaking from the mapped folder on the Docker host. Inside the container, it is still /var/proget/packages. Does this still happen on the latest version of ProGet? We did make some changes to how the headers are returned in the latest version, especially for feeds that require authentication. Thanks, Rich

Hi @sebastian, Thanks for sharing your thoughts on this! Few things to point out... [1] The "Missing Package Problem" is not as bad in ProGet 2024, mostly because it will only apply when there's a license rule. In ProGet 2023, a "missing package" would happen even for vulnerabilities. [2] We're working on a new feature/module (tentatively called "Remote Metadata") that is intended to routinely cache/update meatdata from public repos like nuget.org, npmjs.org, etc. This feature enables two usecases: Routinely update "server-side metadata" like Deprecated, Unlisted on cached packages Fetch metadata for packages not in ProGet during build analysis It works somewhat independently, and basically it'll just show up on the Admin tabs as like "Remote Metadata" and you can configure providers, urls, etc. I hope to have a prototype in a couple weeks and will post some details on a new forum posts. As an FYI this is something we will limit in the Free/Basic editions and have full-featured in the ProGet Enterprise product. [3] "Package In ProGet" could be a policy rule to add after RMetadata feature, though it's probably not a big deal if ProGet can detect licenses thanks to RMetadata Best, Alex

@guyk thanks for letting us know; unfortunately this would require a substantial change to the way we handle authentication on connectors; if we see more of this down the line we'll definitely consider it further :)

@saml_4392 in theory it's fixed, but we didn't test it Could you open a new thread about a creating a Helm chart for ProGet itself? That'd be a great place to start that discussion, and get community direction and feedback from users - and provide nice opportunities to partner with organizations like bitnami, who could help

PyPI support has now been added and published as a pre-release version of 5.2.0. Visit the ProGet Versions page to download, or get it from the Inedo Hub download.

Discussion should be moved to a new post or followed here: http://inedo.com/support/questions/6554

I've now found a cleaner way of adding this entry to the host file... If using docker run, add the argument: --add-host=<host_server_name>=127.0.0.1 if using a docker compose file, add an entry: extra_hosts: - "<host_server_name>: 127.0.0.1"

@apxltd Thanks for the update. I really appreciate you taking the time The reason I was looking to see if you supported winget yet is that I was replacing my own machine and I like to rebuild our developer image as I do so. I build our image from a base Windows image that has current Windows. I then run the “winget install” scripts to install the common tool chain. I understand on your side it doesn’t seem like a workable solution, but I love it. Winget works as if I downloaded and installed all the installs manually. Then I can just run “winget upgrade” to see what needs to be upgraded. The main benefit is that the upgrade check works even if a developer or I install something without using winget to install it. This is because “winget upgrade” uses Windows installed apps (as seen in appwiz.cpl) for its check. I hope they cleanup the backend so you could look at this product again.

Hi @bbrown2_8761 , It's a bug in Visual Studio's NuGet client I'm afraid and it's not something we can realistically work-around You could post it in the NuGet issues, and they may fix it in a future version; https://github.com/NuGet/Home/issues It's really easy to reproduce, and they've definitely fixed issues like this in the past. Cheers, Alana

Since there is no further update and no solution for my problem using nuget cli or dotnet cli I am closing this thread.

Hi @scroak_6473, Glad to hear it! Thanks, Rich

@sneh-patel_0294 I don't think so, its only displayed on that page...