Hi @stevedennis ,

Thanks for the clarification.

Yes, we do have download blocking configured, and we're also performing build scanning in our CI/CD pipelines.

We're a little hesitant to disable download blocking because our concern is developer experience. If the first time a developer discovers they've introduced a noncompliant package is when they raise a pull request (or when the build pipeline runs), that can result in wasted effort and rework late in the development cycle.

What would Inedo recommend as the preferred approach for identifying noncompliant packages earlier in the process?

I had a look at pgutil builds scan, but unless I'm misunderstanding how it works, it appears to upload the SBOM to ProGet for analysis. We don't currently provision every developer with a ProGet account, so I'm struggling to see how we'd integrate that into a local developer workflow.

Is there a recommended way for developers to get feedback on package compliance before committing code, without relying on download blocking in the feed?

Thanks,
Dan

Hi all — looking for advice/workarounds.

We’re using ProGet as our NuGet V3 feed. If we unlist a package version in ProGet UI, it disappears from Visual Studio Manage NuGet Packages browsing (expected), but restore still treats it as available.

The version is still returned from:
/v3/flatcontainer/<package-id>/index.json

In our case:
• OpenTelemetry.Api 1.13.1 is unlisted/deprecated
• restore still attempts: /v3/flatcontainer/opentelemetry.api/1.13.1/opentelemetry.api.1.13.1.nupkg
• download returns HTTP 400
• restore/build fails

So metadata appears inconsistent: version is advertised in flatcontainer index but package blob is not retrievable.

Questions:

1. Is this expected behavior for ProGet “unlist”, or a feed inconsistency?
2. Is there a ProGet setting to exclude unlisted versions from restore metadata?
3. Is there a recommended reindex/cleanup task to remove stale versions from flatcontainer index?

Thanks for any guidance.

Some versions of certain packages produce 404 responses in the UI.

Error from the log:

An error occurred in the web application: FluentAssertions 8.9.0 not found.

URL: https://redacted/FluentAssertions/8.9.0
Referrer: https://redacted/FluentAssertions/versions
User: Daniel
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36
IP Address: ::ffff:10.1.2.4
Stack trace:    at Inedo.ProGet.WebApplication.Pages.Packages.PackagePageBase.CreateChildControlsAsync()
   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)

::Web Error on 30/04/2026 14:26:51::

Why is this happening and how can I fix it?

Yes, you're right.
I cleared the cache with nuget locals all -clear, after which I could no longer install the same package via Visual Studio or the command line.

Thank you for pointing this out to me.

I’ve spent some time configuring licenses in ProGet and expected them to prevent certain packages from being consumed, but I’m seeing inconsistent behaviour.
For example, I created a custom license rule covering FluentAssertions versions 8.0 and above, and marked them as noncompliant. This appears to work correctly in the ProGet UI. Those versions cannot be downloaded.
However, this restriction does not seem to apply when installing packages via Visual Studio or the NuGet CLI. I’m still able to install those same versions without any issue.
To rule out external sources:

I’ve disabled all package sources in Visual Studio except our ProGet instance
I’ve explicitly specified the ProGet feed URL when installing from the command line

So I don’t believe the packages are being pulled from elsewhere.

Expected behaviour:
Marking a package/version as noncompliant should prevent it from being installed via the feed.

Actual behaviour:
The restriction is only enforced in the UI; installs via NuGet/Visual Studio are unaffected.

Is this the intended behaviour? If so, what is the purpose of marking packages as noncompliant?
If not, is there an additional setting or configuration required to enforce this at the feed level?

Web UI Version: 2025.20 (Build 23)
Database Schema Version: 25.0.20.23