Fix verified on 2024.2 version. Thank you.

Hi @pbinnell_2355, Looks like the example code was incorrect. I've updated it. When a dotnet tool is installed globally, you run it by just running the tool name directly, so pgutil instead of dotnet pgutil Hope this help! -Greg

@rick-edwards_9161 that is correct, these will only be developed for ProGet 2024

I set our metadata caching to 10000 queries over 24 hours. I will reduce to the default first and monitor. Thanks Dean

Hi Dean Thank you This is helpfull. I will dig a little bit and let you know if I found something. Best regards PhilippeC.

@jw we'll definitely keep this in mind, it doesn't look trivial based on our usage of that marked library Personally, I always try to keep the Diagnostic Center clean and empty, so when new issues show up I can easily spot and address them. Sifting through messages that are basically spam, without being able to filter or ignore them costs me more of my time that I would like to invest for monitoring. We do not recommend using the Diagnostic Center for proactive monitoring. It's only intended as a tool for troubleshooting things like connector or 500 errors that you / end-users encounter. There are a lot of non-problem errors and warnings logged that aren't worth time even looking at.

Makes sense, thanks for the quick fix. Cheers

Thanks I made a backup and ran the script and it did clean up quite a few rows. I'll try upgrading to 2024 again next week after we released :)

Maybe I'm getting old and 14px seemed to small In addition, we don't display a lot of textual information so the larger font size seemed to fill out the whitespace nicer, particularly in tables (which there are a lot). I was never really all that happy with how this filled out whitespace (from ProGet 2023): [image: 1714496162493-5e3d33ea-33a0-40ed-9391-667a1aa74c60-image.png] I'm not thrilled about ProGet 2024, but it felt like an improvement... and most importantly, "something different" than past few years: [image: 1714496179530-07c12e78-8715-4620-acdd-d9fac38b564e-image.png] That said, for ProGet 2025 I'd love to do a much more notable style refresh (logos? etc?), perhaps even some navigation tweaks. So open to ideas there

Hi @rmusick_7875, I'm afraid API endpoints are not customizable and we do not support doing "reverse proxy" or otherwise rewriting the URLs. Hopefully this will be a good chance to make the endpoint-url more easy to configure/change - this will be important, as you may wish to move to multiple feeds, etc. Good luck, Steve

Hi @greg-swiderski_0221 , It looks like there is an "Object reference not set to an instance of an object" error that's occurring while trying to connect: 2024-04-30 09:52:41,341 8256 [WARN ] - Unable to connect to source 'http://localhost:8624/nuget/approved-choco/': Object reference not set to an instance of an object. That error is presumably occurring from the Chocolatey client (choco), and unfortunately there's no way to know what it means. Most likely, it's an "error reporting an error" message, but it's hard to say. You could use some HTTP monitoring software (Fiddler Classic, Wireshark), and see if ProGet is returning an error of some kind.... but even if so, choco should report that error. I would check with the chocolatey team on this one. Thanks, Steve

@stevedennis Thanks for the updated version - it works smoothly now.

@rhessinger Wonderful, thank you very much and credit to Pawel Ostrowski who also did a lot of investigation on this

@atripp, I can confirm that 2024.1 works great [image: 1714370821747-4773ef8b-6788-46cc-9907-f9c184fd69ba-image.png]

@dan-brown_0128 I understand So you'd either have to upgrade (where we fixed the code) or reassess it to Low so npm audit won't crash. I suppose you could also patch npm audit so it doesn't crash.

Hi @stefan-kiryazov_8753 , Thanks for the inquiry; I've updated our Other feed types docs with a link to this thread. On a first glance, it looks like a CocoaPod itself is just a basic text file that acts as a "pointer" to a GitHub repository. The pod client uses the git client to "download" files and tags for versioning. In other words, there is no package file. A CocoaPod repository is a Git repository, and the pod client seems to just use git client to commit/push files to the repo. In other words, there is no API for ProGet to implement. Here is what a CocoPod repo looks like (note how it's just a bunch of files in a Git repo): https://github.com/CocoaPods/Specs/tree/master/Specs To make a "private repo", you basically just create a Git repository: https://guides.cocoapods.org/making/private-cocoapods This means that ultimately to implement a CocoPods repository, your only option is to create a private Git repository? That's my inital assessment at least. And of course, we have no plans to add Git source code hosting to ProGet :) From here, I recommend to ask the developers to research this a bit more, and maybe contribute their thoughts? It just doesn't seem like the iOS devs uses packages - it's all very open-source and just GitHub repositories. Steve

Thanks for the quick reply! I'll wait until the next build is released before testing the fix. Since I have a lot of other tasks on my plate right now, and the rollback to 2023 worked perfectly, there is no particular rush Cheers

Hi @lucas-almeida_8120, This a known issue that we are currently working through. It seems to be an issue with some bad/duplicate data in your database. The current workaround is to downgrade to ProGet 2023. We are hoping to have a fix ready soon. Thanks, Dan

Hi @proget-markus-koban_7308, Thank you for all the extra detail. I was able to recreate this issue and fix it as part of, PG-2628. This fixed will be released this Friday in ProGet 2023.34 and 2024.1. Thanks, Rich

Hi @v-makkenze_6348 , Thanks for the report; please ignore this, it should not be logged in the Diagnostic Center. It's addressed via PG-2625 in ProGet 2024.1 Cheers, Alana