@itops_6398 glad that worked! I noticed same quirk in the UI and fixed it :) Probably why we/no one noticed before... editing the connector just happened to fix it once the value was saved.

Yes, reindexing the directory adds (and optionally removes) files wich were/were not present when the asset feed was setup. We have an existing directory of files which are downloadable by another service. We would like to make (and have made) that directory available as an asset feed in Proget. It's easy enough to point Proget to the existing directory for the feed, and have it index it. This creates the metadata within your system, making the files available to those users who are valid to download them. If I were to add files via a drop directory, it would work, but it would not necessarily add them in the structured manner we have setup in the base directory. Although TBH I haven't tried dumping a directory tree into a drop directory to see what happens. I'll try that. Thanks.

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

Sure. I've logged that change as PG-2508. It should be easy enough to make that URL configurable in ProGet.

Yep, you are awesome. I know this is an old post, but it was my issue as well. Using a nginx proxy for the server. Thank you.

Hi @Jon, Looks like this was a result of recent change. I have fixed this in OT-499 and will be released in Otter 2022.15. If this is an immediate requirement, I can create a prerelease version of Otter you can install. Please let me know if you are interested. Thanks, Rich

Hi @schuettecarsten_9427 , There's no limitation about that in ProGet... the * is something the NuGet client resolves. Based on the error, it looks like there's a problem with Visual Studio communicating to ProGet. No further information is provided; maybe this is related to ProGet having an issue communicating to Nuget.org through your connector. You'd need to dig into that a bit further. I'd also make sure to use the V3 API Endpoint. The query that's shown in the error is the v2/ODATA endpoint. Cheers, Alana

@philippe-camelio_3885 oh wow, great find. Hmmm..... so I guess that must be some kind of UI bug with not trimming the newlines variable.ListValues = variable.Type == VariableTemplateType.List ? txtListValues.Value?.Split(new[] { Environment.NewLine }, StringSplitOptions.RemoveEmptyEntries) : null; I'm sure this should be fixed eleswhere too, but for now I'll just add | StringSplitOptions.TrimEntries and I guess that will at least fix the UI bug

@Dan_Woolf Thank you I've now produced a dashboard using this API to show my GREEN/RED status without requiring a login. I know its a lot to ask but adding dashboards public would be amazing in Otter. My code is only about 6 lines but not sure how much effort this is to add into Otter.

Hi @ssuenaga_1020 , Thanks for the detailed report; this seems easy enough to fix, so we'll get this addressed in the next maintenance release (2023.20) via PG-2499. Cheers, Alana

Hi @e-rotteveel_1850, Thanks for reporting this; we'll get this fixed via PG-2498 in ProGet 2023.20 (in two weeks). Cheers, Alana

Ahh that could be it, I will update to latest version and try it again :)

Sorry for my late reply, but we have since installed version 2023.16 and repodata.json works perfectly fine now! Thanks for including this in your updates.

@lucas-almeida_8120 it's hard to say; it's likely due to some kind of operating system configuration or issue that's preventing the service from restarting. We haven't seen this happen very often, and restarting the web is not a common activity. It's probably not worth spending time investigating or trying to resolve, especially given the age of the server. You'd probably have to look at the Windows service logs to find what the issue might be.

Hi @hashim-abu-gellban_3562, I see a few issues here... First, the URL you're using is not correct; the easiest way to to find the url by clicking the "download package link" in the ProGet UI. It will look like this: /nuget/your-feed-name/package/your-package-name/your-version-number Second, you're downloading a file - so you want to use a powershell command like this: $url = "https://myprogetserver/feeds/mynuggets/package/mypackage/1.0.0" $destination = "c:\mypackages\mypackage-1.0.0.zip" Invoke-WebRequest -Uri $url -OutFile $destination Best, Steve

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

Hi @caterina, Here is the final solution: When using the auto type and scanning for NuGet and npm dependencies: The default configuration should be to omit dev dependencies and scan the node_modules directory When using the npm type and a package-lock.json file is specified The default is to only scan the specified package-lock.json file and omit dev dependencies When using the npm type and a package-lock.json file is not specified The default configuration should be to omit dev dependencies and scan the node_modules directory Each of these options would have an optional parameter to include the dev dependencies (--include-dev) Each of these options would have an optional parameter to ignore pacakge-lock.json files found under node_modules (--package-lock-only ) This has been implemented in pgscan 1.5.6 which I will be pushing shortly, and these options will be added to BuildMaster 2023.2. Thanks, Rich

@gdivis Thank you

Hi @k_2363, We cannot get the endpoint ApiKeys_CreateOrUpdateApiKey to get to work. It seems that the JSON requires ApiKeyTasks_Table (IEnumerable1)`. Unfortunately we cannot find what we have to provide here. If i look at the Stored Procedure, it seems that this cannot be filled with an API request. Hmm, it looks like you may not be able to use table-value parameters via JSON. I don't know how easy that will be to add support for; one option is just to just do direct INSERT statements into ApiKeys and ApiKeyTasks tables. I'm aware of at least one other user that does that, since it was significantly easier to do a single statement that joined on another table in another database on the same SQL Server. It's not ideal, but this is pretty rare use case. Would that work? Thanks, Steve