Topics created by jw

Hey @atripp, Thank you for that snippet, very insightful. Oddly enough that issue is still on the .NET 8 Planning milestone, even though .NET 8 was already released this November. Ah.. one shall not question Microsoft's planning... ;)

Hi @jw , Thanks for reporting these! We'll get the fixed in hopefully the next upcoming maintenance release via PG-2520 and PG-2521 Cheers, Alana

Thank you for the pointers. I think I finally got it working, though I must admit I'm still not a 100% sure what combination in what order actually led to success. I'm already in contact with @apxltd about your planned SCA changes. I will try to write up what tripped me as part of that feedback.

Thanks for the additional feedback; this is definitely something we're revisiting for ProGet 2024. As you described, a lot of the pieces are there - they just aren't wired together very well in some cases. We're working on redesigning this to be more cohesive. A lot of the existing behavior has to do with performance. For example, /packages/from-purl?pUrl=... is a bit of a "hack" that we used. It's the navigation URL, then then redirects you to the proper URL. This is because finding the URL of a package can be expensive, especially when there are 1000's of packages in a SBOM and multiple candidate feeds for each package. Doing big joins across multiple feeds on the FeedPackages is something we need to very carefully do. On the same performance note, "Pulling from the source" can be expensive -- especially when you aggregate multiple feeds into one using connectors. So we need to be really careful before doing that. But like I said, this is something we are redesigning in ProGet 2024; you can think of ProGet SCA features as a "2.0" right now (I guess "1.0" was the old package consumers feature?), and hopefully "3.0" will be a lot closer to getting it right. Cheers, Alana

@jw thanks for the bug report! We'll get this fixed in the an upcoming maintenance release via PG-2491 :)

Hi @jw , The version number is a bit buried in the logs I believe, but it sounds like things are working now... and it's too much of a guessing game to figure out what might have happened now. Cheers, Steve

@lm thanks for letting us know that it worked! I'm glad you were able to find the issue on GitHub. Looking closer, it is a NuGet client bug; I posted an update on the issue. The only workaround is what you described (setting a separate API key).

You're right, caching SourceLink enabled PDBs would be somewhat useless for outages. Though there are still plenty of "old-school" PDBs around, especially for native code (C/C++).

Ok, thanks for the information.

Hi @jw , Ah, I can see how that would happen; I logged this as PG-2425 and we'll try to get it fixed in the upcoming maintenance release. Steve

Hi @lm, We do not currently have any way to be actively notified on new ProGet releases outside of the notification in ProGet. We do, however, perform regular releases of ProGet and we typically release them every 2 weeks. The best place to check for updates would be the https://my.inedo.com/dowloads page or the Offline Installers page. Thanks, Dan

Hi @lm , We've considered this over the years, but realized it'd be more engineering effort that just changing cookie duration; we'd want to track login sessions on the server side, allow them to be invalidated, etc. It's possible, but it seems the "Remember me" function on most services (GitLab, etc.) seems to be very forgetful anyways (for security purposes), and with Integrated Windows Authentication and browsers managing passwords, it seems not so valuable for the effort. Cheers, Steve