Posts made by jw

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:

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

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!

First of all thanks for adding the ability to list all packages for a given license on the package usage overview page (PG-2783), very helpful feature.

There seems to be an issue with listing packages that are matched to custom licenses. We have added a number of custom licenses to ProGet, to deal with proprietary packages that do not have OSS SPDX identifiers.

When clicking on the link to list the packages on such a custom license there is a 500 error on the next page:

Stack trace from error log page:

Stack trace: at Inedo.ProGet.WebApplication.Pages.Licenses.ListLicensePackagesPage.CreateChildControls()
at Inedo.ProGet.WebApplication.Pages.ProGetSimplePage.InitializeAsync()
at Inedo.Web.PageFree.SimplePageBase.ExecutePageLifeCycleAsync()
at Inedo.Web.PageFree.SimplePageBase.ProcessRequestAsync(AhHttpContext context)
at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

Ahh, took me a while to get it, but this is the dialog I was looking for.

It wasn't quite clear that the orange "Package Status is Deprecated" is actually a policy violation dialog, which is overriding this one here.

Thanks again.

Hello @atripp

Thanks for the feedback.

Just to double check: When the box shows "Package Status is Deprecated" it should also contain the custom deprecation reason, right?

Right now the box looks like in my screenshot above and I could not find any place where one could read the custom reason.

Or am I just looking in the wrong place?

Hi @rhessinger

Works like a charm, thanks.

Have a nice weekend.

ProGet Version 2024.15

1. Deprecation reason not visible

The custom deprecation reason does not seem to be visible anywhere anymore. If I recall correctly it was visible both in the ProGet UI and also Visual Studio.

VS package manager:

Any chance something got broken when that field was changed from a dropdown to a textbox?

2. License policy violation overrides deprecation status/reason

When a package is marked as deprecated and it also violates a license policy, the deprecation reason are not visible in the info box, instead only the license message is shown.

It would be good if the deprecation state and reason would always be visible regardless of policy compliance.

Inedo.ProGet was never updated on nuget.org since the initial deployment compared to pgutil. It looks like there have been a number of interesting additions looking at the source.

Any chance this package can be updated?

Always releasing it together with pgutil would also be appreciated.

Thanks for adding it to the roadmap.

From what I can see so far, there haven't been that many changes in the spec. For us mainly the author field changed.

Right now there is no immediate need. It might arise in the future if improvements or fixes are only being made available in the CycloneDX 4.x tooling.

@rhessinger

CycloneDX .NET Runner 4.0.0 was just released and produces spec version 1.6 by default.

Do you guys already have plans for supporting this?

Hi Alana,

the API would have been my next option, thanks for the pointers to the scripts.

My colleagues want to use the deprecation feature in connection with SCA to better communicate package states.

When packages are being deprecated it is usually more than one package that is affected.

Could this bulk edit feature be implemented in the UI?

Is there any way to apply the unlisted/deprecation status to multiple packages at once?

In case no, is this something that could be added as a bulk edit option on the package/versions/all page?

Thanks

Hi @stevedennis

Let's continue this thread here: EDO-10681

Hi Steve,

I tried restarting via Manage Service, restarted both Windows services manually and rebooted the whole VM.

The issue does not seem to go away.

Version 2024.11 (Build 10)

A new exception is created navigating on the web UI or just pressing F5.

An error occurred in the web application: Nullable object must have a value.

URL: https://192.168.x.x/0x44/ProGet.WebApplication/Inedo.ProGet.WebApplication.Controls.Layout.NotificationBar/GetNotifications
Referrer: https://192.168.x.x/administration/logs
User: xxxxxxxxxx
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
Stack trace: at System.Nullable`1.get_Value()
at Inedo.ProGet.WebApplication.Controls.Layout.NotificationBar.GetNotificationsInternal(AhHttpContext context)
at Inedo.ProGet.WebApplication.Controls.Layout.NotificationBar.GetNotifications(AhHttpContext context)
at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

@v-makkenze_6348

See this topic for additional information on the subject:
https://forums.inedo.com/topic/4152/proget-sca-2024-preview-feedback-package-detection-still-hit-or-miss

Thanks for the feedback and the fix.

Have a nice weekend.

Thanks for the quick fix.

We didn't have that many packages assigned to the licenses in question, so the workaround of disconnecting all packages from a license and then deleting that license did the trick.

We are encountering the following exceptions, when pushing to the ProGet Docker registry:

Error scanning blob 487afa63fba9 (id=1793): The archive entry was compressed using an unsupported compression method.

System.IO.InvalidDataException: The archive entry was compressed using an unsupported compression method.
at System.IO.Compression.Inflater.Inflate(FlushCode flushCode)
at System.IO.Compression.Inflater.ReadInflateOutput(Byte* bufPtr, Int32 length, FlushCode flushCode, Int32& bytesRead)
at System.IO.Compression.Inflater.InflateVerified(Byte* bufPtr, Int32 length)
at System.IO.Compression.DeflateStream.ReadCore(Span`1 buffer)
at ICSharpCode.SharpZipLib.Tar.TarBuffer.ReadRecordAsync(CancellationToken ct, Boolean isAsync)
at ICSharpCode.SharpZipLib.Tar.TarBuffer.ReadBlockIntAsync(Byte[] buffer, CancellationToken ct, Boolean isAsync)
at ICSharpCode.SharpZipLib.Tar.TarInputStream.GetNextEntryAsync(CancellationToken ct, Boolean isAsync)
at Inedo.ProGet.Feeds.Docker.BlobScanner.DockerBlobScanner.ScanBlobAsync(DockerBlobs blobData, Stream blobStream, ILogSink log)

It appears that the exception is coming from blobs that are just docker manifests in JSON format which are not compressed.

The manifests are created and pushed with the docker manifest command.
https://docs.docker.com/reference/cli/docker/manifest/

There's no problem deleting the deprecated licenses and adding their SPDX identifiers to the new licenses. When you delete a license, it will remove the association with packages.

Trying that results in the following exception:

(500) Server Error
547`16`0`Licenses_DeleteLicense`12`The DELETE statement conflicted with the REFERENCE constraint "FK__LicensePackageNameIds__Licenses". The conflict occurred in database "ProGet", table "dbo.LicensePackageNameIds", column 'License_Id'.

[1] is somewhat expected behavior, as some older versions of ProGet allowed non-normalized URLs to be added; newer versions should not allow this. We do not plan to "clean-up" the data at this time, but if you're "brave" you could could like do it with some API/DB calls

I'm actually hoping that the normalizing the URLs design decision would be revisited at some point. Modifying the URLs has a number of unwanted and unneeded side effects as I described further above.

[2] This is probably some quirk related to older data, but you can probably just cut the items to clipboard, save the license, the edit again, and it should work-around the quirk

I did some more digging:

A number of SPDX identifiers got deprecated and replaced, see bottom of the page here https://spdx.org/licenses/

New ProGet installations only ship the new identifiers, this means there is no conflict, but mapping packages to those deprecated license identifiers, like LGPL-3.0 will probably not work, unless there already is special code for it..?

Existing ProGet installations still have deprecated license identifiers like LGPL-3.0 in their databases and the URLs of those are now in conflict with those of the new identifiers like LGPL-3.0-only.

In my case I could solve it by deleting the deprecated licenses and adding their SPDX identifiers to the new licenses.

That said, I could only delete the deprecated licenses after no packages were referencing them anymore. In my case I was lucky since only a few packages were affected, other customers might have a harder time with that.

Not fully sure that is the proper solution though, so feedback is welcomed.

Related: https://docs.debricked.com/product/license-risk-management/proxying-non-standard-license-identifiers

Two related issues came up (Version 2024.9):

1. There is currently a mixture between URLs with www. and without prefix in the database. Saving a license entry causes existing URLs to be modified in the database. So even if one just wants to add another URL to the list, existing entries are modified.
   Storing license URLs without modification and applying additional logic, like ignoring www. subdomains, during comparison still seems like the sensible solution here.

2. LGPL licenses (and possibly others) cannot be saved at all, due to an URL collision.
   

I found another 403 error on the /vulnerabilities page in 2024.9. This should probably not show up during production (this is from my test system), but I thought I'd still report it.

Hitting the button without permissions, results in a 403 popup. I'm not quite sure if non-admins should be able to view this message at all..?

Our leading system, when it comes to deciding what state a build is in, is our build server. So, it does not really make sense for us to maintain this state in another system.

Also, similar to you guys, we are a product-based business, so we need to assume that all our stables releases are in production somewhere at any time.

In ProGet we just want to see how issues with our dependencies (license, vulnerabilities) are changing over time. To keep down the "CI beta build spam", we will either use the archiving feature or maybe even clean out old beta builds since it makes no sense to keep tracking those.

Sounds like a plan. :)

Thank you, once more.

In this case, allow me to sneak in my feedback instead. ;)

At the moment we are not planning to use the "build pipelines" feature at all. So from our point of view, it would be good if there was a way to opt-out of it.

For this page that would basically mean the previous behavior: When one clicks on a project and the "build pipelines" feature is disabled, it would directly navigate to the "all builds" page like before.

@stevedennis

Was the 3rd point addressed yet? I tried clearing the browser cache, but it still looks like this for me in 2024.7:

It's unlikely we will want to add/change this; what you're describing isn't a supported use case, and adding a "second URL" type field that would be empty on nearly every license would be confusing.

Makes sense.

Though, I don't quite understand why the URLs are modified in the first place. Ignoring protocols and subdomains during comparisons is something that could be done in code. A small hint in the UI that there is no need to add all URL permutations should do the trick. This would cover both uses cases and no information is lost.

Our general recommendation for dealing with non-OSS licenses has been to create a code like DEVEXPRESS or ASPOSE, and treat them as all the others.

Not sure what you mean by "code". The CylconeDX Spec says for licence Ids only valid SPDX license IDs must be used same goes for SPDX License Expressions, they list the valid values in the spec.

That is why for proprietary licenses we chose "Option 2" of specifying a name + url instead.

If there's more user demand for the particular use case we'll definitely reconsider. For now the licenses are confusing enough :)

Alright, let's see if there are more users with similar use cases. Right now it looks like we jumped on the SBOM/SCA bandwagon a bit too early. ;)
I'll try to find a workaround.

With version 2024.7 the bulk edit button is once again visible on the packages page, even though users do not have delete or promote permissions in any branch.

From the changelog:
PG-2711 2024.7 FIX: Bulk edit button hidden unless user as Admin_Configure [PG-2651 Regression ]

It gives users without permissions the impression that they could delete packages. Then when they actually click it, nothing happens and they contact Admins with support requests about a "broken ProGet". This is very time consuming and annoying.

Could you please fix this properly? As it stands right now it is back to the original behavior with bad usability.

Hello @atripp

Is this something that could be added?

We could really use this functionality to deal with proprietary licenses that do not have OSS SPDX identifiers.

Currently we add a custom license to the ProGet license database, then map either via license URL or via PUrls and then we modify the incomplete SBOM to to add a proper license name and URL to the component.

The only issue right now is that we cannot get the original unmodified license URL back out of ProGet.

Maybe a field could be added to the General tab that optionally holds an unmodified license URL for a license?

{
    "External_Id": "Custom-DevExpress-EULA",
    "License_Id": 628,
    "Title_Text": "DevExpress EULA"
    "Official_License_Url": "https://www.devexpress.com/Support/EULAs"
},

When saving a license URL to the license database in ProGet, both the protocol scheme and the "www" subdomain gets dropped.

As a consequence it is impossible to get the original URL, e.g. when reading the license definition back out via API. It is impossible to tell if the scheme was http or https or if www. was present in the original URL or not.

While URLs might currently be considered deprecated in NuGet (actually just the field in the nuspec spec is deprecated, but there is no replacement yet), in context of SBOM it continues to be a valid way of specifying license information. CycloneDX Spec

Is there any way I can configure ProGet to not manipulate URLs when they are saved to the database?

Example:

/api/json/Licenses_GetAllLicenseData response:

{
    "License_Id": 635,
    "License_Url": "testing.com/EULA"
}

Inconclusive Analysis

A build package (and thus a build as a whole) can be have an "inconclusive" compliance status. This will occur when two conditions are met:

1. A rule would cause the build package to be Noncompliant, such as Undetected Licenses = Noncompliant or Deprecated = Noncompliant
2. The package is not cached or otherwise pulled to ProGet, which means ProGet doesn't have enough information about the package to perform an analysis because the package is

Not sure I fully understand condition 1. Even if not such rule is configured, compliance could not be established because licensing information is not available, due to the package being not cached. Am I missing something?

The analysis message is incorrect however, it should be "Package is Warn because of Package Status is unknown, No license detected."

Should the string really say "Warn" when the package state is Inconclusive? Aren't Warn (Policies failing, Vulnerabilities detected, etc.) and Inconclusive (Package not found) two mutually exclusive states..?

I haven't investigated this yet, but I assume that the results are the same in the UI? That's all just pulling data from the database, so I would presume so.

Yes, the UI shows the same.

Could you find the relavent parts of the analysis logs? That helps us debug much easier.

It was actually not that easy to find the AutoMapper package in the logs, since the name does not appear anywhere. I made a custom SBOM with just the AutoMapper package and this is what the log looks like:

Analyzing compliance...
Beginning license rule analysis...
Default rules: undectableLicense=Warn, unspecifiedLicense=Compliant
The package is not cached or local to any feed; without package metadata, license detection is limited.
No licenses detected on package; applying undectableLicense rule (Warn)
License rule analysis complete.
The package is not cached or local to any feed; cannot determine if Deprecated.
No policies define a deprecation rule, so default Warn will be used.
The package is not cached or local to any feed; cannot determine if Unlisted.
No policies define an unlisted rule, so default Warn will be used.
Package is Warn because of Package Status is Unlisted, Package Status is Deprecated, No license detected.

[1] Based on the stack trace, I think the issue is that one of the SBOM documents you uploaded has a Component with a null/missing Purl field. Obviously this should error, but that's what the error must be looking at the code. If you can confirm it, that'd be great.

Yes, we are adding components with type Application that represent parts of our product into the SBOM via CycloneDX libraries. As these do not come from a package manager, they do not have a purl.

According to the spec that should be ok.
https://cyclonedx.org/docs/1.5/json/#components_items_purl

[2] ProGet is considered the "source of truth", so a new SBOM document will be generated based on the build packages. That SBOM will then be augmented with some information in the original SBOM(s), such as component "Pedigree", "Description ", etc.

Good to know, thank you.