Hi,
We are running 2x ProGet servers in High Availability behind a load balancer. We are only seeing the load balancer IP on the package download statistics in ProGet.
We have enabled X-Forwarded-For on the load balancer to forward on the Client-IP but this has had not had any impact. Is there another header value we should be sending? Apologies if this is documented somewhere, I couldn't find it!
Thanks,
Ashely
Thanks @atripp, that makes sense.
I was having another issue with pgutil which turned out to be my fault, however I believe there is a follow on issue to do with the compliance analysis for project builds that have yet to have been pulled to ProGet. More detail on my original post here: https://forums.inedo.com/topic/5733/proget-unable-to-publish-sbom-from-pgutil/4.
@Dan_Woolf suggested continuing the topic here as it's related to non-compliant packages and what I believe to be the recently published rule. Is this something you can take a look at?
Thanks!
Hi @Dan_Woolf
I had to restart my computer so I lost my PowerShell variables, but I'm going to say you were correct. I ran it again and didn't get the errors - my bad!
This might be for a separate thread, but after providing the correct inputs 
, ProGet thinks every build package is noncompliant, but if I click into one of the packages which takes me to the feed, the package is correctly reporting as compliant.
Project Build:
Example Package Feed:
If I analyze my Build again, this is part of the log output (too long to post the entire thing):
Using recently cached (04/05/2026 09:06:59) metadata.
Analyzing compliance for Azure.Core 1.47.1...
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
The package is not cached or local to any feed; cannot determine Publish Date.
Policy "Global" considers recently published (7 days) Noncompliant
The package is not cached or local to any feed; cannot determine Publish Date.
No policies define a latest patch, so latest patch will not be checked.
Analysis resulted in a Noncompliant result.
Azure.Core 1.47.1 is Noncompliant Package is Recently Published
Using recently cached (04/05/2026 08:35:56) metadata.
Analyzing compliance for Azure.Identity 1.14.2...
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.
Package is deprecated.
Policy "Global" considers deprecation Warn
Policy "Global" considers aged packages (3 years) Warn
The package is not cached or local to any feed; cannot determine Publish Date.
Policy "Global" considers recently published (7 days) Noncompliant
The package is not cached or local to any feed; cannot determine Publish Date.
No policies define a latest patch, so latest patch will not be checked.
Analysis resulted in a Noncompliant result.
Azure.Identity 1.14.2 is Noncompliant Package Status is Deprecated; Package is Recently Published
Using recently cached (04/05/2026 08:35:56) metadata.
Analyzing compliance for Microsoft.Bcl.AsyncInterfaces 8.0.0...
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
The package is not cached or local to any feed; cannot determine Publish Date.
Policy "Global" considers recently published (7 days) Noncompliant
The package is not cached or local to any feed; cannot determine Publish Date.
No policies define a latest patch, so latest patch will not be checked.
Analysis resulted in a Noncompliant result.
Microsoft.Bcl.AsyncInterfaces 8.0.0 is Noncompliant Package is Recently Published
Using recently cached (04/05/2026 08:35:56) metadata.
Analyzing compliance for Microsoft.Bcl.Cryptography 9.0.4...
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
The package is not cached or local to any feed; cannot determine Publish Date.
Policy "Global" considers recently published (7 days) Noncompliant
The package is not cached or local to any feed; cannot determine Publish Date.
No policies define a latest patch, so latest patch will not be checked.
Analysis resulted in a Noncompliant result.
Microsoft.Bcl.Cryptography 9.0.4 is Noncompliant Package is Recently Published
Using recently cached (04/05/2026 08:37:50) metadata.
Analyzing compliance for Microsoft.Data.SqlClient 6.1.1...
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
The package is not cached or local to any feed; cannot determine Publish Date.
Policy "Global" considers recently published (7 days) Noncompliant
The package is not cached or local to any feed; cannot determine Publish Date.
No policies define a latest patch, so latest patch will not be checked.
Analysis resulted in a Noncompliant result.
Microsoft.Data.SqlClient 6.1.1 is Noncompliant Package is Recently Published
Using recently cached (04/05/2026 08:35:57) metadata.
Analyzing compliance for microsoft.data.sqlclient.sni.runtime 6.0.2...
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.
Policy "Global" considers aged packages (3 years) Warn
The package is not cached or local to any feed; cannot determine Publish Date.
Policy "Global" considers recently published (7 days) Noncompliant
The package is not cached or local to any feed; cannot determine Publish Date.
No policies define a latest patch, so latest patch will not be checked.
Analysis resulted in a Noncompliant result.
microsoft.data.sqlclient.sni.runtime 6.0.2 is Noncompliant Package is Recently Published; No license detected
From a brief look at the logs, i'm guessing this is to do with out recently published rule not being calculated for packages that are yet to be cached locally. We are trialling this prior the the build step, so we can't make the assumption that a particular package version will be cached locally in ProGet when running pgutil scan.
Any help is much appreciated.
Thanks,
Ashley
Hi @atripp,
I upgraded to the latest ProGet version and the package is now complaint if it's older than 7 days but less than 8 days. Unfortunately, it looks like packages that are newer than 7 days (but older than 6) are now compliant. I guess this makes sense if you removed the time component in the comparison.
Examples:
Time now: 2026-05-04T09:53:00 (GMT)
Package published date: 2026-04-27T09:45:00
Outcome compliant 
Time now: 2026-05-04T09:53:00 (GMT)
Package published date: 2026-04-27T15:00:00
Outcome compliant 
(It should be Noncompliant)
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 04/05/2026 08:41:11
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 "npm-public"...
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
No policies define a latest patch, so latest patch will not be checked.
Analysis resulted in a Compliant result.
I'm guessing that a for a full fix it needs to compare the time of the package in UTC against UTC time on the server in addition to the date.
P.S: I only just noticed that there's a typo in Set Package Status for "Publihsed date:"
af87249d-4355-4cd3-8b69-4bd62ef8b731-image.png
Thanks for all your effort on this.
Ashley
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.
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).
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:
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.