Hi,

I am trialling the SBOM functionality in ProGet using pgutil builds scan but it errors when trying to publish the SBOM to ProGet.

 pgutil builds scan --source=$Source --api-key=$ApiKey --input=$ProjectPath --project-name=$ProjectName --version=$ReleaseNumber
Scanning for dependencies in .\REDACTED.csproj...
Publishing SBOM to ProGet...
Server responded with InternalServerError (500): 547`16`0`Projects_CreateOrUpdateProject`44`The INSERT statement conflicted with the CHECK constraint "CK__Projects__Project_Name". The conflict occurred in database "REDACTED", table "dbo.Projects", column 'Project_Name'.
Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 1, current count = 0.

Server: ProGet 2025.25 (Build 11)
Database: Microsoft SQL Server 2019
PgUtil: 2.2.7

I am able to create a project from the Web UI, but the pgutil error is still present after manually creating the project in ProGet.

Hi @atripp,

Thanks for investigating and implementing a fix so quickly! It was always going to be something to do with a developers worst nightmare, time & timezones

I'll update to the maintenance release after it's out and let you know our findings.

Hi @atripp,

Perfect thanks! I was able to recreate the behaviour with the metadata override and Reanalyze Package feature.

Server date now: 2026-04-21 14:52BST (13:52 UTC)
Package published date: 2026-04-14T13:00:00
Reanalyze package outcome: Non-compliant

There appears to be an issue uploading images at the moment, but heres the log:

Package "pkg:npm/%40hono/node-server@1.19.14" will analyzed with local data
Attempting to update local package with remote metadata...
Cached metadata from search on 21/04/2026 13:01:56
Detecting licenses for "pkg:npm/%40hono/node-server@1.19.14"...
Found 1 licenses: MIT
Detecting vulnerabilities for "@hono/node-server" version "1.19.14"...
Found 0 vulnerabilities.
Searching policies associated with feed "xxxxxxxxxx"...
Found 1 policy to use for analysis.
Beginning license rule analysis...
Default rules: undectableLicense=Warn, unspecifiedLicense=Compliant
Checking MIT against rules...
No matching license rules; applying unspecifiedLicense rule (Compliant)
License rule analysis complete.
Policy "Global" considers aged packages (3 years) Warn
Policy "Global" considers recently published (7 days) Noncompliant
Publish date of 14/04/2026 is considered recently published.
No policies define a latest patch, so latest patch will not be checked.
Analysis resulted in a Noncompliant result.

and the failing npm install:

npm i -g @hono/node-server@1.19.14 --cache ./c
npm error code E400
npm error 400 Bad Request - GET https://xxxxx/npm/npm-public/%40hono/node-server/-/node-server-1.19.14.tgz - Package is Recently Published
npm error A complete log of this run can be found in: xxxxx

Hi @atripp,

I understand that min-release-age and the Recently Published rule refer to two different products, but that version of the package at that time should have been compliant in ProGet, but it wasn't. NPM correctly resolved the right version of the package.

This is obviously quite hard to re-test with the Reanalyze logs because you need a package that's just over the Recently published rule. I don't see a way in the ProGet UI of updating the published date so that I can test it?

We want to block packages from being installed on developer machines in addition to CI pipelines without additional tooling requirements.

Thanks,
Ashley

Hi,

There appears to be some disparity between the npm min-release-age and the ProGet Recently published rule on the feed.

Setup

ProGet 2025.25 (Build 11)

.npmrc:

registry=https://my-proget-server/npm/npm-public/
min-release-age=7

ProGet Use Connector Publish Date enabled.

ProGet npm feed has Recently published (7 days).

Install

Run npm install for the latest applicable version of @hono/node-server

> npm i @hono/node-server@latest
npm error code E400
npm error 400 Bad Request - GET https://my-proget-server/npm/npm-public/%40hono/node-server/-/node-server-1.19.14.tgz - Package is Recently Published

In Proget @hono/node-server-1.19.14 has a publish date of the 2026-04-13 02:20:00:

I ran the npm install on 2026-04-20 15:12 BST, minus 7 days is 2026-04-13 15:12 BST. That's greater than the ProGet npm package date of 2026-04-13 02:20:00.

If I change my npm config to have min-release-age=8, then the install works fine. Is this some issue with timezones?

Thanks!

Hi

We updated to 2025.9 and NuGet packages are now being displayed with incorrect casing in the Visual Studio Package Manager.

ProGet 2025.9:

Nuget.Org:

It only appears to be an issue on packages we had not downloaded before the update to 2025.9.
This may or may not be related to this post: https://forums.inedo.com/topic/5477/packages-with-noncanonical-names-errors-on-internalized-packages?_=1757496394015

Hi,

We upgraded to 2025.9 after testing in our dev environment and ProGet is now importing PyPi packages from the drop folder

Thanks!

Hi @atripp,

I really appreciate you looking into this and sorting a fix so quickly. I'll hold off until the patch this Friday - we can temporarily work around the issue by manually uploading individual packages.

Thanks,
Ashley

Hi,

We upgraded our Windows ProGet instance to 2025.7 and are now seeing issues with the ProGet feed drop paths not importing files. It detects files dropped into the folder but the warning path it outputs is a weird combination of the feed storage and the import path.

Our configuration:
Feed name: pypi-internal
Feed type: PyPi
Storage Path: E:\.pypi\F5
Drop Path: C:\ProGetDrop\pypi-internal
ProGet version: 2025.7 (Build 12)
Windows Version: Windows Server 2019

Local Service Output

DEBUG: Found C:\ProGetDrop\pypi-internal\mypythonpackage-0.9.0-py3-none-any.whl
WARN: Error installing package: The filename, directory name, or volume label syntax is incorrect. : 'E:\.pypi\F5\mypythonpackage\0.9.0\C:\ProGetDrop\pypi-internal'
DEBUG: Deleting files...
DEBUG: Indexed 0 packages in pypi-internal feed.

Note that the Warning path is incorrect for a the file that is in: C:\ProgGetDrop\pypi-internal\mypythonpackage-0.9.0-py3-none-any.whl

The service has access to the directory and this was working fine before the upgrade. Any help is much appreciated.