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

Hi @apxltd, Wow, that was fast... I noticed that this was apparently already implemented in 2023.5 (PG-2359). Just wanted to let you know that I tested this with 2023.6 and it works like a charm

Hi Dean, Setting RaftItemType_Code = 7 in this instance worked for me. Appreciate the list of valid types. Thanks for all of your help! Scott

Hi @nkerifacclaud_6931, Thanks for testing this out! I will get it released as a production version today! Thanks, Rich

After futzing with the certs on the proget host vm, it looks like we've got full connectivity to the chocolatey.org feed as well as nuget.org. Can someone remind me/point me to docs around the difference between connector caching of packages vs. the "pull to proget" function? thanks!

Hi @Darren-Gipson_6156, No problem! Glad it is working. ProGet 2024.6 will include a fix for this issue, PG-2695. So hopefully this won't happen again! Thanks, Rich

Hi @viceice, I did a few searches and have you tried setting the hostsProxyHeaders> Maybe something like this: traefik.frontend.headers.hostsProxyHeaders=www-authenticate? The docs make it sound like it will look in those headers for URLs that are proxied. You could give that a shot. Thanks, Rich

Installed 1.0.7, and no issues to report with our network share backed feed. Thx.

Hi @jyip_5228, That may be your issue. NuGet is currently on version 5.7. Could you please try upgrading your NuGet.exe and see if that fixes the issue? Thanks, Rich

I've managed to get this working in v5.0.11 by setting up the second ProGet website in IIS with anonymous authentication enabled and pointing to the same physical path as the original website. The same AppPool is shared between the two and is using the Integrated pipeline. No other IIS or .config configuration was required. In ProGet, for the npm feed that required anonymous access I added the Anonymous user to the feed permissions under Administration > Security > Users & Tasks. Restarting the web services then enabled the anonymous access to the feed using the second website's bindings.

@jyip_5228 FYI, as part of ProGet 5.3.10 release, we shipped the ProGetCore container image as well. You can follow the normal steps in the Linux and Docker Installation Guide to install/upgrade, but just use progetcore for the container instead of proget. Aside from support for the Lucene-based Maven feed indexing (in progress), it seems to be feature complete. And of course, if there are problems, you can switch back to proget:5.3.10 or downgrade as needed (no database schema changes). For example, docker pull proget.inedo.com/productimages/inedo/progetcore:5.3.10

If you upgrade to the latest v5.6 (currently 5.6.11), then it should work OK!

@kichikawa_2913 glad it's working now, you seem to have found the issue. FYI, you can also configure that value from Advanced Settings page under Admin.

Doubled checked and verified that ASP.NET 4.5 (or later) is already installed.

Hi @viceice, That error is safe to ignore. It is currently a known bug and we are looking to fix that in an upcoming version of ProGet. The ticket tracking the fix for the log message is PG-1841. Long story short, the ProGet service correctly detected that the product wasn't activated, and then logged that message. But it was doing it every time it accessed license information, which is on every connector health check, replication run, etc. Activation happens automatically as soon as someone visits the Web application, and re-activation is required after upgrading certain versions. Thanks, Rich

Any updates on this? I encounter the same issue and none of your comments helped .

@Joshua_1353 sorry about that, I missed it. As you can see from the flurry of commits I just made to your repository, I'm simply not experiencing the problem. I tried this with both a Secure Credential, and without. Here's what I discovered during my testing the Git Raft Editor isn't very clear about "keeping the same password" if it's unchanged, but that's what happens GitHub doesn't seem to look at the username? I entered invalid usernames and it worked fine the PAT permission required seems to be "public_repo Unless you have something that's "doing something" between Otter and GitHub, I think that: you made a typo or something in your PAT; you can't have any spaces, it must be exactly a PAT, so make sure to edit and save it your PAT doesn't have right permission From here, about the onloy thing you could do is attach a proxy server like Fiddler between Otter and GitHub, and see specifically what traffic is flowing through. But like I said I think it's one of the above to

I must be missing something here, but if you remove the View Only privilege to download packages, you should be forbidden from downloading packages... Are you saying you removed your View Only privileges, or that you removed them from the Anonymous User such that it has no privileges? If it's the latter, can you send a Fiddler trace containing the requests that Visual Studio extension is attempting to send?

@stevedennis I swtiched from "V3: Active Directory (LDAP)" to "V4: Active Directory/LDAP (Preview)" and all is good now. Logon went from two/three minutes down to one second.