Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Noncompliant packages can still be downloaded
-
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 lineSo 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
-
Based on what you've described, it sounds like ProGet is indeed blocking downloads; this is visible in the ProGet Web UI with a "Download Blocked" indicator. If you try accessing the download URL, you will in fact get a
400error.However, NuGet/Visual Studio aggressively cache package - which means they aren't even attempting to download them. If you clear all the NuGet caches (system, user, http, project, etc), then it should attempt to download then again.
That said, as of ProGet 2026, we no longer recommend downloads. This is one reason, but there are more reasons.
Here's an work-in-progress article that discusses our new guidance:
https://guides.inedo.com/vulnerability-management/containment/Cheers,
Alana
-
Yes, you're right.
I cleared the cache withnuget 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.
