Hi @zakaria-smahi_2127, That badge looks like something generated by a CI-server, and I think it's showing the latest version or tag or something related to a release branch? I don't have much context. It's not something that ProGet (a package manager) would generate, since all of the packages in ProGet are considered "published". Our CI/CD platform, BuildMaster, can generate these badges: https://docs.inedo.com/docs/buildmaster-ci-cd-continuous-integration-server-badges Cheers, Alana

Hi @gurdip-sira_1271, Just to let you know, Otter v2022 has been released; from here it'd be best to start a new thread if you have a specific issue -- we'll be happy to help! Steve

Hi @fabian_7019, Thanks for bringing this to our attention. I was able to recreate the error and we will get this fixed in the next version of Otter, 3.0.25, which is due out next Friday. This looks to only be an issue when there is only one raft repository setup in Otter. As a workaround, if you create a second raft repository under Administration -> Raft Repositories, you will then be able to create new folders in the default raft. The fix is being tracked in ticket OT-461. Thanks, Rich

@atripp Thanks for the pointers. Investigations did indeed reveal that proget was replying with the http url if FindPackagesById() request and that the subsequent redirect back to https was causing the credential to be dropped from the request. I've configured the BaseUrl with advanced settings and confirmed success with that in place. I now have a functioning proget instance and I'm able to efficiently work with the repo from Powershell. Much appreciated!

Hi @mcascone , I think that was a feature that got lost in 5.3, with the new UI. Easy enough to bring back, I think, so we'll add it via PG-2134 Cheers, Alana

@atripp Thanks, I was able to enable the v3 api for my feed. Just in case anyone else stumbles on this the v3 api url was actually https://MY.FQDN/nuget/MYNUGETFEED/v3/index.json. Visual Studio does correctly hide the unlisted versions using the v3 api, thank you.

Hello dean-houston, thank you very much for your answer. I have been able to solve the problem with our network team. The networkers had to make one more setting in the proxy. thx

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

@nkumari_3548 you'll likely want to check with your network team for help on this one ProGet is a standard web application, and will listen for all traffic on the port you've configured. If you want to access ProGet with proget.my-company.corp, then you'll need to have someone configure appropriate domain/DNS records, etc. You may also need firewall settings, and a certificate for HTTPS. https://proget.inedo.com/ is our public instance of ProGet. It's not intended for direct access by users, but by tools like docker or Inedo Hub. You can't login to it.

Just as a follow-up on the solution. This error came from a Git Repository Monitor. The Docker Image for Build Master does not include git installed out of the box. This will require you to either install git on the running container or use a BuildMaster Agent/SSH server to be added and to run this on there. The other issue was that the repository monitor was using a secure resource from a specific application, so the repository monitor needs to specify the application it uses as well.

OK, I got it. the servers are the ssh servers tha BM is connecting to while deploying. As this is a test env, there are a lot of faulty servers Thanks for the help, Marc

Thanks, yeah, that seems to work. I changed my pipeline code to not send any title metadata to ProGet, which returned that field in the UI to its original behavior. I also found that rebuilding an existing package, and sent to ProGet with the updated pipeline, has the same effect.

Thanks for letting us know, @hwittenborn We must not have the http --> redirect setup in our DR server , we'll try to get that soon

Hi @marc-ledent_9164, Thanks for following up and letting everyone know that this fixed your issue! Thanks, Dan

Hi @marc-ledent_9164, Thanks for following up and letting us know that fixed the issue. We are currently in the process of cleaning up our activation process in the v2022 versions of our products. This issue should be corrected in the next major version of our products. Thanks, Dan

You can ignore this error; for whatever reason, the NuGet client unexpectedly terminated the connection, and the result was that ProGEt stopped writing bytes. Not really anything to worry about. The diagnostic center isn't for proactive-monitoring, more for diagnostic purposes. So ulnless users are reporting a problem, you don't need to check it.

@rmusick_7875 generally speaking feed information is combined from chocolatey.org (and other connectors you configure), metadata stored in the database (the NuGet* tables), and cached/local package files on disk

@Dan_Woolf Thanks for the explanation. I'll try it as soon as I can re-activate my trial license...

Hi @alin-kovacs_4228 , We don't maintain documentation for that version I'm afraid; the Native API is available, and you can find it in the software with /reference/api However, your best bet would be to work with our team to figure out what you need to do and get some help migrating to a newer version or something :) Cheers, Alana

Awesome! Thanks for the quick reply!