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.

There is updated documentation with step-by-step instructions here:

https://docs.inedo.com/docs/installation-windows-https-support#configuring-https-on-the-integrated-web-server

@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.

The Usage & Statistics page (feeds/some-feed/System.CodeDom/8.0.0/usage) suggests that this package version is part of the scanned project.

When navigating to the package list of that linked "Latest Version" the project it shows what version of said package is actually contained in the project.

In the current state the Usage & Statistics page is not very informative or helpful as it gives users the impression that a particular version is used in the project which in reality is not. Yes, the right information is obtainable by following the version link, but that does not really solve the issue with the page itself.

It would be good if the tables both on feeds/some-feed/System.CodeDom/8.0.0/usage and also on feeds/some-feed/System.CodeDom/versions/usage could be changed to show the concrete version of the package that is used in the project version that is currently listed.

Is this something that could be changed?

Hi @atripp,

We haven't updated the production instance to the version that introduced this feature yet, so nobody breathing down my neck. ;)

I'll wait for the official release, but thanks for the offer.

Have a nice weekend!