Hi @dean-houston

Thanks for the implementation.

A remark:
Both delete APIs have a bit odd behavior when it comes to return codes. They both always return 200 OK when anything was supplied, no matter if the project name (and version) matched anything to be deleted or not. Wouldn't 404 be more appropriate for the "I couldn't find anything to delete" case?

Also I would like to renew my wish to automatically deploy a new version of Inedo.ProGet when something in pgutil was changed.

Hi @atripp

Once again thanks for the quick fix.

I was actually worried that something got messed up in our database, while trying to fix the duplicate package issues, but so far everything looks good.

Also I should probably start making it a habit of stating that we're still on SQL Server, instead of having you guess. ;)

There might be a regression from the recent fixes for the issue in this thread.

One of the packages with changed names is Microsoft.NETCore.App.Runtime.win-x64 (the "NetCore" part is different now).

Recent vulnerabilities, like PGV-2576347, are no longer matched to recent package versions.

Flagging stops at the 8.0.2 version but should go up to 8.0.20.

Any chance that these package names are compared case-sensitive against the PGV database which breaks the matching for renamed packages?

Hi,

I've been looking to delete old builds from SCA, but cannot find any API endpoint for that.

All I could find was the option to archive builds, but that is not really what we need.

For projects there is at least the native API Projects_DeleteProject, but in the regular API the delete endpoint is also missing.

Could you add these missing endpoints?

However, as you noticed, the name is overwritten when a package is added to a feed. So, if jquery is the package name stored in the database, that record will be updated to jQuery upon upload of a package.

This was a pretty good hint. So far I've only been hitting the "Download Package" button, which puts the package in the cache, but apparently does not update the name in PackageNameIds. "Pull to ProGet" however seems to update that table and I can fix the old names in the database.

Thank you!

Tested in 2025.15, working as expected now - Thank you!

Hi @atripp

Just tested 2025.15 and the Vulnerability Database Updater does not cause duplications anymore - so thank you for that fix!

A small semi-related issue:

The deduplication during reindex does remove the duplicate entries, but it always leaves the entry with the wrong (old) package name behind.

E.g. when I have no jQuery package in the cache everything looks correct, most likely because the package name is taken directly from the feed:

When I download the package and it gets cached, the database entry seems to take over causing the old package name to be displayed:

Is there any way I can update these packages with changed names to use the newer one?
Maybe this could be an option during reindex?

Hi @stevedennis

I first noticed the issue on our production instance, which is older installation upgraded to 2025.10. The issue is easily reproducible on my test instance, which was just installed from scratch this September.

With database looking like the screenshot above, I ran the feed reindex with both options checked. Unfortunately that seems to clean up the wrong entry, in this case the ID 68622 gets deleted, which still has the old Package_Name.

After reindexing the integrity check is green as expected, but when I run the Vulnerability Database Updater job, the database looks like this afterwards

Running the feed integrity check again, we are back to where we started:

As the title says, after running the Vulnerability Database Updater job, duplicates appear in the PackageNameId table.
This results in the feed integrity checker complaining about the duplicates and suggesting a index rebuild with duplicate cleanup, which does not fix this issue permanently.

As a consequence, we found that in the SCA module the license of the package could no longer be detected, even though clicking on the package still navigates to the package page and shows the license as green.

It looks like packages which had their casing changed in the past are the source of this issue. In our case it happens with the jQuery NuGet package which had the "Q" uppercased.

The first row in the screenshot is present before the Vulnerability Database Updater job ran, the 2nd row appears after:

Microsoft.NETCore.* are also packages causing this issue, apparently the "NET" was uppercased at some point.

According to the NuGet spec, the package id should be handled case-insensitive. There is also this issue in the purl-spec repo.

Is this an issue in our database or something that needs to be fixed on ProGet side?

Just tested the partial updates for licenses. Everything is working smoothly now, so thank you for that.

One issue I noticed:

It looks like there is no cache invalidation after calling _progetClient.UpdateLicenseAsync().

Subsequent calls to _progetClient.ListLicensesAsync().ToListAsync() still return the old data.

The only way to get the API to return the updated data is to reload the /licenses/types page, which seems a bit inconvenient for API usage.

Maybe it would make sense to invalidate the cache on all modifying (Add/Delete/Update) license API calls?

Whoops sorry I keep forgetting - it shows up different on our end. Let me know if you'd like me to update your email on the forums, so you can login with your company account. It's fine either way, but we might forget again -- it shows up as free/community user on our dashboard

Thanks for the offer, I created a ticket EDO-12291 with the information required.

Anyway in that case, sure we can prioritize this for you!

I guess in the end you guys need to sort out the question if you want to support partial updates.

Since you're the first user whose requested this... we'll go with what you suggested. That makes sense to me. I just made this (PG-3137) since it was trivial:

Sounds good, thanks for the fast implementation! I will check it out.

Hi @atripp

Technically it's double, though it's not trivial due to the number of places the change would need to be made and tested... ProGet API, pgutil, docs.

I guess in the end you guys need to sort out the question if you want to support partial updates. They do have advantages, especially for complex objects like in this case, but it indeed requires more effort to implement and maintain.

The code/title change itself looks trivial (i.e. just pass in External_Id and Title_Text to the call to Licenses_UpdateLicenseData), though I'm not totally clear what to do about the other one. What does pgutil send in? Null? []? Etc.

I'd probably do something like this:

C#	JSON	Meaning
List<T> = null	<empty, not serialized> (1)	Ignore during update
List<T> = new List<T>()	[] (empty array)	Clear all items of the reference
List<T> = new List<T>() { Item1, Item2}	[Item1, Item2]	Update the reference to the new list

(1) [JsonProperty(NullValueHandling=NullValueHandling.Ignore)]

As a free/community user this isn't all that easy to prioritize... but if you could do the heavy-lifting on the Docs and pgutil (i.e. submit a PR), and give us a script or set of pgutil commands that we can just run against a local instance... I'm like 95% I can make the API change in 5 minutes.

We are actually paying customers, e.g. EDO-10681 is tied to our actual customer account. That makes it hard for me to justify the development work to our management.

(I kept my forum account from before we were customers to keep the posting history. I failed trying to connect my forum account to the company my.inedo.com account, but that is another story)

@stevedennis said in ProGet 2025.10: License Update API Issues:

And you're right, you can't update code/title, which aligns with the pgutil behavior as well.

Is this something that could be added?

Same question about the partial update behavior?

Right now, as far as I can tell, it is not properly supported. Either null means ignore or null means clear, for a proper implementation three states need to be considered, like I listed above.

Hi @stevedennis

the code seems to explain at least half of the problems I ran into

• It is not possible to update the Title property of LicenseInfo, it is never passed to the DB
• It is not possible to update the Code property of LicenseInfo, it is never passed to the DB
• Partial updates might not be possible, that depends on how DB.Licenses_UpdateLicenseDataAsync handles null values
  At least the code shown here does not differentiate between supplying null or an empty list.
  True partial updates would be something like
  • Null => Do not change the db
  • Empty list => Clear the field in the db
  • Filled list => Overwrite the field in the db

Given that the properties in the LicenseInfo objects are nullable, the code shown here doesn't quite match the intention of partial updates. At least not how it is described in the docs

This endpoint supports partial updating by only updating the properties that are supplied in the request.

It appears the AddLicenseAsync() API also has issues:

• Spdx is sometimes modified, sometimes not set at all
• PUrl is not set
• PackageNames is not set

ProGet: 2025.10
Inedo.Proget: 2.0.5

The Update License API does not update the database in all cases.

For example just updating the title via a partial object (which is supposed to be supported according to docs?) never seems to update the database, even though the call always succeeds.

await _progetClient.UpdateLicenseAsync(new LicenseInfo { Id = 59, Code = "CC-BY-1.0", Title = "Test" });

I've had some success with updating the Urls and PackageNames properties, but even these calls are not always immediately reflected in the database or the UI. Sometimes it feels like the changes only get persisted after clicking around in the UI a bit, but that could just be coincidence. Rarely it is visible directly after the API call.

I've also tried retrieving the full LicenseInfo object from the database, and using a modified clone of the object with the Update API, but this has also flaky behavior and the title update also never works.

Am I doing something wrong or is there a glitch in the update API?

Thank you for the feedback.

I will observe for a while and reserve yelling at people to close their browsers for later. ;)

Hi @stevedennis

I'm not quite sure what to do with this information. Unfortunately the log message contains no information from whom or which IP this exception is triggered.

One question is what is the relation to the package that is mentioned in the Referrer. What could the notification be about?

Another potentially related issue is browser cache busting, which does not seem to work reliably. I have noticed this in the past and also with the upgrade to the 2025 version, that changes in the UI are only reflected after manually cleaning the browser cache or force reloading with Ctrl+F5.

From what I can see in the browser dev tools, some of the css files have a version query parameters, which I assume is meant for cache busting, but others (e.g. proget.css) do not.

Could this be related to the issue, that after the upgrade to 2025, some people are still seeing old versions of the UI and triggering this exception?

After upgrading to 2025.6 from 2024.36 we occasionally have the following exception in logs. It is not quite clear what exactly triggers it.

An error occurred in the web application: Could not load file or assembly 'ProGet.WebApplication, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.

URL: https://xxxxxx.local/0x44/ProGet.WebApplication/Inedo.ProGet.WebApplication.Controls.Layout.NotificationBar/GetNotifications
Referrer: https://xxxxxx.local/feeds/xxxxxxxx-nuget-proxy-telerik/Telerik.UI.for.AspNet.Core/2025.2.702
User: (unknown)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Stack trace:    at System.Reflection.RuntimeAssembly.<InternalLoad>g____PInvoke|49_0(NativeAssemblyNameParts* __pAssemblyNameParts_native, ObjectHandleOnStack __requestingAssembly_native, StackCrawlMarkHandle __stackMark_native, Int32 __throwOnFileNotFound_native, ObjectHandleOnStack __assemblyLoadContext_native, ObjectHandleOnStack __retAssembly_native)
   at System.Reflection.RuntimeAssembly.InternalLoad(AssemblyName assemblyName, StackCrawlMark& stackMark, AssemblyLoadContext assemblyLoadContext, RuntimeAssembly requestingAssembly, Boolean throwOnFileNotFound)
   at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
   at Inedo.Web.Handlers.DynamicDelegateHandler.GetHttpHandler(GetHandlerParams args)
   at Inedo.Web.Handlers.DynamicHttpHandling.GetHandler(AhHttpContext context, String requestType, String url, String pathTranslated)
   at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

::Web Error on 31.07.2025 17:06:40::

When opening https://xxxxxx.local/feeds/xxxxxxxx-nuget-proxy-telerik/Telerik.UI.for.AspNet.Core/2025.2.702 the package site is shown and also the package can be downloaded without any problem or exception.
Deleting the package from the cache and repopulating the cache did not help either.

Opening https://xxxxxx.local/0x44/ProGet.WebApplication/Inedo.ProGet.WebApplication.Controls.Layout.NotificationBar/GetNotifications in a browser returns the following page:

For every reload of this page, a new entry of the same exception shows up in the logs.

Hi @stevedennis

Thanks for the quick response and fix.